environm e nt in which need e d application code is downloaded and r e sid e s for an extend e d period 
of time on th e us e r's comput e r, is download e d to the client comput e r. 

Summary Of The Invention 

A method for improving interface efficiencies between networked or otherwise 
communicating computing devices is provided. Enabling code is provided to enable and/or 
initiate the interface between a remote computing device and a local computing device. This 
enabling code is downloadable in a format suitable for making possible substantially instant 
utilization of the enabling code, even while additional portions of the enabling code continue to 
be downloaded to the local computing device. This enabling code will preferably allow terminal 
emulation by a client computer , a s well a s allow further ex e cutabl e cod e to be download e d in th e 
background, in ord e r to support som e l e v e l of fat - cli e nt support for a softwar e application which 
may b e us e d by th e client us e r. 

In a preferred embodiment of the subject invention, the enabling code provides a terminal 
emulator by which the client computer may access application software resident on a server. 
Preferably, the server computer which executes the application program transmits presentation 
data to the client computer on an instantaneous or near instantaneous basis, so that the terminal 
emulation is transparent to the client user, i.e., so that the experience of the user is similar or 
identical to using a fat client executable application. A s th e e nabling cod e and oth e r softwar e 
continues to be downloaded from the remot e computing device to the local computing d e vic e , a 
us e r is fr ee to use oth e r data such a s application or file data, r e sid e nt at or through e ith e r th e 
remot e computing d e vice or th e local computing d e vic e . In on e e mbodim e nt of the inv e ntion, 
following completion of the download of e nabling data of th e us e r is, optionally, advis e d of a 
transition s e qu e nc e automatically occurring to t e rminate the application or data download phas e 
and fully op e rat e within e ith e r a local computing d e vic e mod e or a mod e in which file s ar e 
s hared with th e local computing devic e via th e r e mot e computing d e vic e . 

Also provided within an embodiment of the present invention is a system for distribution 
of data files between and among remote users. In a preferred embodiment of the invention, 
information about the location of a remote server may be embedded in a web page viewed with 
the WWW application, or through e-mail, e.g. the SMTP protocol. Within these communication 
media would also be embedded information about the remote file to be accessed by the recipient 
of the communication, and the server application to which the remote file is native. The file, 
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residing on a central server or being uploadable to the server, will also preferably contain 
information regarding permissions granted to various remote users, including modification, 
saving, and viewing permissions, together with duration parameters. 

In an alt e rnate embodiment of the inv e ntion, th e e nabling code method may be 
incorporat e d into a system and method for incr e a s ing th e utility and attractiv e n e ss of an 
e l e ctronic data s e rvic e to us e r s ; th e m e thod comprising multipl e st e p s . A first st e p includ e s 
providing e nabling cod e m e ans to r e gist e r users which may permit c e rtain application and other 
softwar e to b e availabl e to th e r e gi s t e r e d us e rs. In on e e mbodiment of th e subj e ct inv e ntion, this 
e nabling cod e softwar e may b e provid e d to th e us e r fr ee of charge. A configurable databas e may 
also b e provid e d and i s mad e accessible to r e gist e red us e rs having th e enabling cod e m e ans. A 
user customized databas e i s configur e d and built using us e r - re s pons e qu e ri es p e rtaining to a 
plurality of sp e cific pr e f e r e nc e s of e ach us e r. P e rmissiv e action means are provided for us e by 
th e us e r to optionally designat e p e rmi s siv e us es of the pr e fer e nc e data according to the user's 
desire. In an alternativ e e mbodim e nt of th e pr e s e nt inv e ntion, a system of incr e asing us e r utility 
may be provided which do e s not utiliz e e nabling cod e m e ans, wh e r e an alt e rnativ e syst e m of 
us e r auth e ntication is provid e d for. 

In on e e mbodiment of th e pr e s e nt inv e ntion, th e application and docum e nt sharing and 
collaboration m e thod described above is coupl e d with a consum e r or custom e r habits and 
pr e f e r e nc e s databas e , by which cu s tom e r - controll e d acc ess to information is provid e d to 
subscribing bu s iness es , according to the r e straints dictat e d by th e cu s tom e r. Th e application 
sharing syst e m may b e provided, for e xample, as a fr ee s e rvice to giv e custom e r s an inc e ntiv e to 
participate in th e pr e f e rence databas e . Other cu s tom e rs may be expected to participate based on 
th e conv e ni e nt access to purchasing and product information, tailor e d to their intere s ts, that is 
afford e d by th e database. 

Brief Description Of The Drawings 

Figure 1 is a depiction of the process flows in creation of an application link according to 
one embodiment of the present invention. 

Figure 1 is a stat e diagram of one embodiment of a system according to th e present 
inv e ntion. 

Figure 2 is a schematic illustration of a network according to one embodiment of the 
present invention. 
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Figure 3 is a screen view of one embodiment of a computerized method according to the 
present invention. 

Figure 3b is an alternate implementation of the screen view of Figure 3. 
Figure 3 c is a depiction of an application interface selection interface according to the 
prior art. 

Figure 3d is a depiction of a file metadata interface according to the prior art. 

Figure 4 is a schematic illustration of the network of Figure 2, as perceived by a user 
according to the present invention. 

Figur e 4 b is a d e piction of tho g e n e ral data flows between several groups of entiti e s 
according to an e mbodim e nt of th e present inv e ntion. 

Figure 5 is an interface screen capture of a computerized method according to one 
embodiment of the present invention. 

Figure 5b is an alternate implementation of the screen capture of Figure 5. 

Figure 6 is a d e piction of the proc e ss flows in cr e ation of an application link according to 
on e e mbodim e nt of th e pr e s e nt inv e ntion. 

Figure 6 is a table demonstrating the use of false identities to achieve optimum 
application interfaces under various file access scenarios. 

Figure 7 is a depiction of the temporal process in the creation of an application link 
according to an embodiment of the present invention. 

Figure 8 is a depiction of the data flows relating to part of the creation of an application 
link according to one embodiment of the present invention. 

Figure 9 is a depiction of the data flows relating to the transmission of an application link 
according to one embodiment of the present invention. 

Figure 10 is a depiction of the process flows relating to part of activation of an 
application link according to one embodiment of the present invention. 

Figure 10b is a depiction of the process flows relating to another part of the activation of 
an application link according to one embodiment of the present invention. 

Figure 1 la is a depiction of a screen view relating to the transmission of an application 
link according to one embodiment of the present invention. 

Figure 1 lb is a depiction of a screen view relating to an alternate manner of transmission 
of an application link according to one embodiment of the present invention. 
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Figure 1 lc is a depiction of a user interface screen capture relating to an unavailable link 
according to an embodiment of the present invention. 

Figure 12 is a depiction of a process flow relating to the creation of a guest account for 
access to application link according to one embodiment of the present invention. 

Figure 13 is a depiction of process flows relating to the encrypted transmission of an 
application link according to one embodiment of the present invention. 

Figure 14 is a depiction of process flows relating to dynamic changing of file accessed by 
an application link according to one embodiment of the present invention. 

Figure 15 is a depiction of a process flow relating to a file presented as static accessed by 
an application link according to an embodiment of the present invention. 

Figure 16 is a depiction of process flows relating to the control of client capabilities for 
an application link according to one embodiment of the present invention. 

Figure 17 is a depiction of process flows relating to an alternate manner of control of 
client capabilities for an application link according to one embodiment of the present invention. 

Figur e 18 i s a d e piction of process flows r e lating to a dynamic cli e nt display according to 
one embodiment of the present inv e ntion. 

Figure 18 is a process flow diagram for a software rights control system according to an 
embodiment of the present invention. 

Figure 19a is a depiction of a user interface for a communication link according to an 
embodiment of the present invention. 

Figure 19b is a depiction of a screen view for an alternate implementation of a 
communication link according to an embodiment of the present invention. 

Figure 20 is a depiction of a process flow, with corresponding user interfaces, for a 
collaborative communication system according to an embodiment of the present invention. 

Figure 21 is a depiction of a process flow for a collaborative communication system 
according to an embodiment of the present invention. 

Figure 22 is a depiction of a process flow for a collaborative communication system 
according to an embodiment of the present invention. 

Figure 23 is a depiction of user interface for an alternate implementation of a 
communication link according to an embodiment of the present invention. 



9 



Figure 24a is a depiction of user interface for an alternate implementation of a 
communication link according to an embodiment of the present invention. 

Figure 24b is a depiction of an alternate implementation of a user interface for a 
communication link according to an embodiment of the present invention. 

Figure 25 is a depiction of a user interface for a collaborative communication link 
according to an embodiment of the present invention. 

Figure 26 is a depiction of a user interface for an alternate embodiment of the present 
invention. 

Figure 27 is a process flow diagram for an e-mail server according to a further 
embodiment of the present invention. 

Figur e 28 is a proc e ss flow showing corr es ponding user int e rfac es for a softwar e 
registration system according to an e mbodiment of th e pr e sent inv e ntion. 

Figur e 29 is a proc ess flow diagram for a software rights control syst e m according to an 
embodim e nt of th e pr e s e nt inv e ntion. ' 

Figure 30 is a data flow diagram showing metafile serv e r op e ration according to an 
embodim e nt of th e pr e s e nt inv e ntion. 

Figur e 3 la is a proce s s flow diagram showing m e tafile server operation according to an 
e mbodim e nt of th e pr e s e nt inv e ntion. 

Figure 3 lb is a s yst e m archit e ctur e diagram of a metafile s e rver syst e m according to an 
e mbodim e nt of th e present invention. 

Figur e 32 is a d e piction of a m e tafil e s e rv e r entry according to an e mbodiment of th e 
pr e s e nt invention. 

Figur e 33 is a proc e ss flow diagram of alt e rnativ e m e tafil e s e rv e r proc e ss e s according to 
an e mbodiment of th e pr e s e nt invention. 

Figure 3 4 a is a proc e ss flow diagram d e picting the creation of a shortcut to an application 
link according to an e mbodiment of th e pr e s e nt invention. 

Figur e 31b is a process flow diagram depicting the activation of a shortcut to an 
application link according to an e mbodiment of the pr e s e nt inv e ntion. 

Figure 35- 28 is a process flow diagram depicting the creation of an application-file link 
interface according to one embodiment of the present invention. 
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Figur e 36 is a process flow diagram depicting th e int e raction of a custom e r, v e ndor s , and 
a Custom e r Pr e f e r e nce and Personalization Databas e according to on e e mbodim e nt of the present 
invention. 

Figure 37 is a process flow diagram d e picting the creation of cu s tomer contact 
opportuniti e s by a Custom e r Pr e f e r e nc e and P e rsonalization Database according to on e 
embodiment of th e pr e s e nt invention. 

Figur e 38 is a proce s s flow diagram depicting th e auction of custom e r contact 
opportuniti e s to v e ndor participants of a Custom e r Pr e f e r e nc e and P e rsonalization Databas e 
according to on e e mbodim e nt of th e pr e s e nt inv e ntion. 

Figure 39 29 is a process flow diagram depicting the opening of an application/file 
hyperlink in the sender's online file system, according to one embodiment of the present 
invention. 

Figure 40 30 is a process flow diagram depicting the setting of application/file hyperlink 
properties, according to one embodiment of the present invention. 

Figure 40B 30 A is a process flow diagram depicting the setting of further application/file 
hyperlink properties, according to one embodiment of the present invention. 

Figure 40B 3 OB is a process flow diagram depicting the setting of further application/file 
hyperlink properties, according to one embodiment of the present invention. 

Figure 40G 3 PC is a process flow diagram depicting the setting of further application/file 
hyperlink properties, according to one embodiment of the present invention. 

Figure 4+ 31 is a process flow diagram depicting the implementation of application/file 
hyperlink recipient properties by online application variables, according to one embodiment of 
the present invention. 

Figure 42 32 is a process flow diagram depicting the notification to an application/file 
hyperlink creator or sender that the link has been activated , according to one embodiment of the 
present invention. 

Figure 43- 33 is a depiction of an existing html-based web portal home page, and an 
alternative to that page, according to one embodiment of the present invention. 

Figure 44 34 is a depiction of a user interface according to an embodiment of the present 
invention. 
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Figure 45- 35 is a depiction of a further user interface according to an embodiment of the 
present invention. 

Figure 46 36 is a depiction of another user interface according to an embodiment of the 
present invention. 

Figure 47 37 is a depiction of a user interface according to the present invention. 

Figure 48 38 is a depiction of a SMTP message that may be issued by a system 
implemented according to the present invention. 

Figur e 4 9 i s a d e piction of a us e r int e rfac e impl e menting an e mbodiment of th e pr e s e nt 
inv e ntion. 

Detailed Description Of Preferred Embodiments 
In one embodiment of the present invention, it is desired to provide a common enabling 
code means for rapid download from communications nets, such as internets, the worldwide 
web, or other providers of such communication download services. Such enabling code means is 
designed to provide a facility for download and upload of data from such communications nets to 
and from desktop, laptop, hand held, or other computing devices of various sizes and capacities. 
However, such enabling code means is designed with substantial commonality and 
interoperability with vast amounts of application and other types of software which is freely 
available on such communication nets. 

As is known in the art, terminal emulation software is available for several popular 
computing platforms, including the Wintel (Windows operating system, Intel CPU) platform. 
Terminal emulation software permits a remote client computer to access a server computer and 
receive GUI or other interface output from the server computer to reflect the operation of an 
executable application, e.g., a word-processing application or CAD program. If the bandwidth of 
the communication network connecting the client and server computers is sufficient, the user at 
the client computer may use the remote application almost as if the application was resident on a 
local hard drive, and was being executed by his local CPU. This, of course, is the traditional 
mode of program execution by a PC owner who purchases off-the-shelf software, and then 
installs it on his machine for use. 

In th e past, no one s ystem ha s b ee n de s ign e d for readily providing acc e ss for a us e r to 
such vast stor e s of fr ee and readily downloadable information. A k e y to this availability, 
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therefore, is enabling cod e m e ans u s ing a common language which is contemplat e d h e r e in. Of 
course, the availability of such va s t s tores of data is one e xampl e of a motivating factor for 
potential us e rs to r e gister to r e ceiv e such s e rvices. In an alt e rnat e e mbodiment of the subj e ct 
invention, advanc e d m e an s ar e provided to a us e r for customizing e ith e r busin e ss or personal 
databas e s in a mann e r that p e rmits p e rmis s iv e us e to a sub se t of users of such data. 

This data may consist of user - created fil e s, docum e nts, or oth e r data which may b e 

generat e d or manipulated by applications off e r e d according to the subject inv e ntion. In an 
alt e rnativ e e mbodim e nt, th e data may con s ist of us e r - pr e f e r e nce or oth e r mark e ting data. 
Exampl e s of preference data include, without limitation, preference items of personal 
information such as name, addr e ss, clothing sizes, hobbi es , intere s ts, p e rsonal pr e f e r e nce s in 
food and drink and clothing, p e riodic n ee ds, information n ee ds, bu s iness n ee ds, consultation 
r e quir e m e nt s and n ee ds, computing needs, situational d e sir e s, pr e ferr e d d e signs of computing 
d e vic e int e rfac es , and th e lik e . These, and oth e r, n ee ds or pr e f e r e nc e s may also b e r e lat e d to a 
specific product, s e rvic e , or proj e ct. For e xampl e , in on e e mbodim e nt, the us e of a p e rsonaliz e d 
database a s d es crib e d abov e may b e to off e r to a n e w us e r a p e rsonalized environm e nt skin, 
t e mplat e , d e sktop, GUI, or other int e rface, which may b e g e n e rally term e d a W e bTop, or oth e r 
communications n e t int e rface bas e d on th e individual us e r's profil e . Alt e rnatively, a busin e ss 
us e r could hav e a W e bTop d e sign or int e rfac e which looks lik e a w e ll known int e rfac e 
e nvironm e nt. Alt e rnatively a youngst e r or on e having t e nd e nci es toward youthful de s igns could 
e njoy s e lecting a W e bTop or int e rfac e d e sign f e aturing primary colors, large selection m e ans 
bas e d on cartoon characters, help m e nus writt e n at the appropriat e r e ading level s , verbal options 
wh e r e e ach program element would v e rbally describ e its function wh e n r e quested via a cursor or 
oth e r simple designation, and oth e r f e atures. In similar fashion, t ee nag e rs may enjoy c e rtain 
f e atur e s and desires, motifs or th e mes. In all exampl es abov e , th e r e may also be options for 
pr e f e r e nce data r e lat e d to gender or oth e r pr e f e r e nc e s. 

In an alternat e embodim e nt of a pr e f e r e nc e databas e , which may bo cither for e xample a 

p e rsonal/consumcr - oricntcd, or a business - r e lat e d preferenc e databas e , the registered us e r may 
b e allowed to navigat e through a proc e ss of starting a busin e ss. For e xample, this may includ e 
b e st options s e lection and linking for writing or having assistanc e in writing a business plan, 
incorporating, d e veloping a mark e ting plan, finding an accountant or l e gal advisor, locating 
onlin e accounting software, finding a tax prof e ssional, finding sourc e s of funds, or oth e r 
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elements of succ e s s fully founding and running a business. Additional r e sources in such a 
database provid e s the user with instant linking connection to various r e gulatory agencies of 
various l e v e l s of government, mark e ting prof es sionals, adv e rtising ag e ncie s , employment 
agenci e s and oth e r resources. An alt e rnat e e mbodiment of the present inv e ntion may provid e 
users with automatic e v e nt planner s p e rmitting extensiv e coordination betw ee n us e r s or oth e r 
third parti e s. 

Y e t another e xample of such a p e rsonalization databas e may includ e , for exampl e , a 

warehous e or clearinghous e conc e pt of p e rsonal data on us e rs. Ind ee d, th e d e gr ee of us e r 
involv e m e nt will alway s determine, to a c e rtain e xt e nt, th e succ e ss or attractiv e n e ss of such a 
databas e to pot e ntial purchas e rs of information th e r e in. How e v e r, in ord e r to optimize th e 
voluntary providing of such p e rsonal information (or busin e ss r e lat e d information) to such 
databases, it is important to provide maximum access control to th e us e r g e n e rating the initial 
data. In this mann e r, it is po s sibl e for th e initial provid e r of th e data to restrict or retract 
authority or p e rmis s ions for c e rtain broad or narrow us e s of the data bas e d on, for e xampl e , 
po s sibl e r e cipi e nts, time considerations, frequency of p e rmis s iv e action authoriz e d, particularity 
as to typ e s of us e rs of th e database information, and oth e r t e chniques. This may g e n e rally b e 
t e rm e d a "p e rmissive action databas e ", or a "custom e r pr e f e r e nc e and p e rsonalization databas e ", 
as d e pict e d in figur e 36. 

In s e rvice - ori e nt e d soci e ti e s and economic s , it i s g e n e rally d e sirable to provid e improv e d 
service to users. Thi s improv e d s e rvic e may be provided, in on e e mbodim e nt of the subject 
inv e ntion, by providing wide - ranging acces s to free software. S e rvic e may also be improv e d by 
provision of means to provide c e rtain busin e ss e s with an opportunity to bett e r servo the primary 
r e gist e red us e rs of thi s system and these m e thods also comprises an improved servic e , wh e n 
d e sir e d, to th e primary users. For e xampl e , the ability to b e tt e r und e rstand th e custom e r's 
p e rsonal tast e s and functional ne e ds and to then maintain that information in a data warehous e is 
v e ry valuabl e to businesses which may serv e us e rs of the pres e nt inv e ntion. The value of this 
information to busin e ss e s may make possible a reduced or fr ee pric e in many instances, for th e 
und e rlying information in the form of application s and oth e r useful softwar e to th e primary us e r. 
In similar fashion, th e data war e house relating to many p e oples' p e rsonal tast e and functional 
n ee ds i s th e n able to be used in a manner to provid e optimum s e rvic e to th e primary us e rs. On e 
e xampl e includes access to a frequent flyer's personal databas e by a s many airlin es as d e sir e 
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such information in ord e r to greet th e flying pa s senger upon boarding th e aircraft with a 
customized product such as individually tailor e d meals, drinks, and n e wspapers and magazin es 
to allow that passeng e r to e njoy th e b e st possibl e service while onboard that particular aircraft. 
Once again, no long e r is it a r e quir e m e nt that th e pas se ng e r be a r e gistered m e mb e r of a plurality 
of airlin e program s nor is it any long e r a r e quir e ment, aft e r use of Applicant's inv e ntion, for e ach 
individual airline or air carri e r to maintain distinctly diff e r e nt programs of e xc e ptional, 
customiz e d s e rvic e to frequ e nt passengers. Rather, such airlines may simply acc e ss th e 
p e rsonaliz e d databas e war e hous e and utiliz e th e mor e particular and specializ e d data on 
passeng e rs or corporations to which s e rvic e is to b e provided. It is r e cognized that v e ndors and 
other servic e provid e rs may also provid e f e e or oth e r r e v e nue or r e sources to such an onlin e 
s e rvic e d e scrib e d by Applicant when such vendors or other s gain business opportuniti e s via th e 
bu s in e ss m e thods, t e chniqu es , and systems describ e d herein. 

Y e t anoth e r example of the valu e of this highly r e fin e d p e rmissive action databas e or 

custom e r pr e fer e nc e and personalization databas e m e thod and sy s t e m r e lates to th e bu s in e ss 
us e rs of th e data in th e database who would oth e rwis e b e compl e t e ly unabl e to afford individual 
polling of such widespr e ad consum e rs and primary provid e rs of the pr e f e r e nc e data. Th e s e ar e 
typically s mall e r companies and individual s e rvic e provid e r s which hav e virtually no m e ans to 
hav e such a particulariz e d and accurate databas e to provid e e nhanc e d s e rvic e to widespread 
portions of targeted us e r populations. 

In ord e r to attract the volume of us e rs nec e ssary to achiev e s ubstantial and critical l e v e ls 

of various database cat e gori e s of information, and to achi e v e this in an e ffici e nt mann e r, it will 
b e d e sirabl e to provid e attractiv e us e r int e rfac e featur es of the int e rfac e betwe e n th e 
communication n e ts and the primary us e rs of the computing devic e s. Indeed, such efficienci e s 
and attractiv e n ess will pr e f e rably e xc ee d th e form e r standards known by such us e rs, or provid e 
such a d e sirable alternativ e that such primary users will n e v e r choos e to partake of the old 
mod e ls of communication interfac e . For e xample, in one embodim e nt of th e inv e ntion, it is 
d e sirabl e to utilize a combination of techniques in allowing simultan e ou s communication 
b e tw ee n a us e r of a computing d e vice and a communication n e t in a mod e which is consid e r e d a 
"thin cli e nt" mode of communication whil e simultaneou s ly permitting the sam e us e r to operat e 
the computing d e vic e in what is consider e d a "fat client" operating mod e . In oth e r words, rath e r 
than simply having a us e r restrict e d to us e of th e particular computing device (laptop, desktop, 
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etc.) for a particular application, it is also possibl e to simultaneously or virtually s imultan e ou s ly 
allow the us e r to acc e ss and download information s uch as usable applications for us e in a "fat 
client" mod e from a communications n e twork while also op e rating in the thin cli e nt mod e . In 
one embodim e nt of th e subj e ct inv e ntion, this e x e cutabl e cod e may be provid e d fre e of charg e to 
attract us e r s ubscrib e rs for mark e ting r e s e arch. Alternativ e ly, th e application code or oth e r cod e 
may b e r e nt e d to us e r s on a pay - p e r - us e system, a subscrib e syst e m, or similar payment structur e 
that i s an alt e rnativ e to a fully paid - up p e rp e tual license. The us e r could us e th e download tim e 
for any applications or softwar e b e ing download e d from a remot e int e rfac e storage location or 
oth e r s yst e m by having th e enabling cod e m e an s to op e rat e on e or mor e portions of th e 
downloading softwar e b e download e d first. Accordingly, this allows th e us e r to actually utiliz e 
th e computing d e vic e during th e download proc e s s in e ith e r a fat cli e nt mod e , such as utilizing 
portion s of the s oftwar e alr e ady r es id e nt on th e u se r' s computing device, or alternativ e ly to b e 
working via thin cli e nt with an id e ntical s e rver - bas e d application to th e softwar e which is 
undergoing a download to th e us e r' s computing d e vice. A stat e transition diagram of 
r e pr e s e ntativ e e mbodim e nt of th e subj e ct inv e ntion is shown in Figur e 1. Figur e 1 shows th e fat - 
and thin - cli e nt stat es which a us e r may b e op e rating in, as w e ll as situations or circumstanc es in 
which a state tran s ition to the alt e rnat e mod e may occur. 

In an e mbodim e nt of th e pr e sent inv e ntion in which access to e x e cutabl e code is provid e d 

to users on a fr ee basis, softwar e may b e provided to th e us e r which is available for littl e or no 
co s t from disparate sources, such a s shar e war e or other open sourc e mov e m e nt software. In an 
alt e rnat e e mbodiment of th e subj e ct inv e ntion, softwar e may b e provided to us e rs which i s 
g e n e rally sold, the us e b e ing support e d by advertising r e v e nu e s. Alt e rnativ e ly, a combination of 
f ee- bas e d subscription and adv e rtising - support e d s e rvice, with users s e lecting th e l e v e l and typ e 
of s e rvice th e y wish to receive. 

Adv e rtising pr e s e nt e d by a free se rvic e according to an e mbodim e nt of th e inv e ntion, 

app e aring as it does on th e thin client WobTop, would preferably b e discr ee t, modest, stationary, 
and where possibl e , related to pr e fer e nc e information submitted by th e registered user. 

Anoth e r embodim e nt of the pr e s e nt invention e nvisions th e simultan e ous download 
f e atur e from a web or other remote communications n e t to a local computing d e vic e 
simultaneous with th e computing device u se r actually working in th e id e ntical s e rv e r - bas e d 
application. When a download is complete, or at any oth e r pre - sclectable tim e , a notification of 
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mode chang e- ov e r may b e made utilizing various cu e ing system s or m e ans a s or e known in th e 
art. At that point, the user may th e n utiliz e th e e ffici e nci e s of the thin cli e nt mod e of op e rating a 
computing device in which a largo siz e program may be acc e ss e d r e mot e ly, with th e larg e size 
program not b e ing download e d to th e computing device of the us e r, but rather acc e ss e d remot e ly 
by that computing d e vic e us e r (and lik e ly by other us e rs simultaneously as w e ll). 

Thus, for various types of software applications, a combination of a thin cli e nt mod e and 
a fat cli e nt mod e , or transition between thin cli e nt mode to fat cli e nt, is highly desirabl e . 
Exampl e s of situation s in which this combination may b e us e ful includ e collaboration s e ssions 
among various t e am m e mb e rs on a proj e ct r e mot e ly locat e d from each other but d e sirous of 
collaborating using both r e lativ e ly small programs as well as a large program suitabl e to a w e b 
bas e d application or simultan e ou s us e , such a s a larg e computer - aided design (CAD) program, 
an advanc e d sch e duling program, or oth e r advanc e d and r e lativ e ly large - scal e softwar e 
program s . Ind ee d, this syst e m may also incorporat e utilization monitoring means for 
automatically e ntering a suitabl e mod e , or by prompting users as to the optimum us e mod e to b e* 
in, as w e ll as record such us e , if d e sir e d, for lat e r us e . A collaboration session is preferably 
initiated by various users accessing a single computer data file, such as a word processing 
document file. The document file, and any software required to view or edit the document file 
may be requested by a remote user by, for example, activating a hyperlink by clicking on a 
document name in an HTML document within the WWW application over the http protocol. 
This link would prompt the remote server to preferably download to the requesting user thin 
client software which, in combination with the information on the server pointed to by the 
AppLink about which file and application to open, allows the user to cause the server to start a 
file-compatible application, open the data file, and present the application to the remote user in 
thin-client mode according to the permissions granted to the user by, for example, the originator 
or other administrator of the document permissions information. The permissions granted to a 
user may preferably be altered on a dynamic basis, for example, where several users view a 
document at one time. In this instance, one user preferably will be granted write permission to 
the data file while all other users are granted a lesser form of permission such as "read". This 
provides version control to the data file and avoids problems with inconsistencies between what 
is ostensibly the same data file from the point of view of the users. In addition to limitations on 
user's rights to write, modify, or delete data files, the present invention preferably may be 
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configured by a data file originator or administrator to allow other users to view a document, but 
withholding permission to the other user's to save the data file. The user may be presented with 
a screen showing various options for security and access provisions for a data file, e.g., a word 
processing file, spreadsheet file, or CAD drawing. 

In an alternate embodiment of the present invention, a thin-client is provided without a 
corresponding fat client mode, but data file collaboration and other related file transfer 
techniques are available to thin client users. This embodiment would allow users to use alternate 
terminal emulation hardware, including, but not limited to, web appliances, personal digital 
assistants, palmtops, and any other devices which are web- or Internet-enabled, or may operate 
over TCP/IP, as is known in the art. 

In an alternate embodiment of the subject invention, upon execution of a hyperlink 
request for a document by a remote user, the user may be presented with a thin client executable 
code which permits viewing and editing of the data file in its native format, replacing the prior 
modes of data submission such as CGI forms. The data file submitting by a remote user in this 
way may later be viewed and edited by other remote users, the form originator, or the user 
submitting data through the native thin-client executable. 

A sch e matic stat e tran s ition diagram showing an e mbodim e nt of th e pr e s e nt inv e ntion is 
d e pict e d in Figur e 1. Figure 1 shows a fat 1 10 and thin - cli e nt mod e 1 12, and various transitions 
b e tw ee n th e s e mod e s. For exampl e , a r e mote user may wish to begin using a softwar e 
application which h e has not y e t load e d on his client PC. Th e us e r may wi s h to operate in thin 
cli e nt mode 1 12 in ord e r to imm e diat e ly us e an application, th e "us e r application" re s iding on a 
r e mot e s e rv e r, without waiting for th e software to download. Th e us e r may op e rat e in a thin 
client mod e 112 if th e us e r has access to a commercial s e rvic e providing access, for e xampl e , to 
a serv e r providing terminal emulation capabiliti es . A definition of thin client as intended by this 
invention may be useful This terminal emulation may proceed by input at the client machine 
being transmitted as instruction requests to the serve r, indicated by 1 14 . Upon execution of the 
instruction request 446 at the server application level, the server web-enabling application may 
modify the GUI or other interface state of the remote user's data file, indicat e d by 118 , as 
returned by the "user application" running on the server, i.e., the application that the remote user 
wishes to use for manipulation of a certain data file. In other words, the user's input on the client 
machine is transmitted to the server, executed on the user application running on the server, and 
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the output of the user application 44$ is sent to the client machine, basically, as a "picture" of the 
server's executable user application output. Because this picture is preferably changed very 
frequently, the experience of the client user is substantially the same as if the user was inputting 
commands to executable code resident on the client machine. This "picture" repeatedly sent to 
the client user may be termed the "GUI state" 448 of the application executing on the server. 
The executable code which allows the client machine to emulate a terminal, i.e., allows the client 
machine to send instructions to the server machine, and display the GUI or other output of the 
client machine, may be considered a component of enable code, and is called commonly a "thin- 
client". If a client machine already has the terminal emulation thin client software installed, the 
enable code downloaded to the client machine may consist solely of the server-based 
application's "GUI State". 

In many cas e s, b e caus e th e input proc e sses of human b e ing s ar e , in comput e r t e rm s , 
e xtr e m e ly slow, significant bandwidth may e xist for th e downloading of data ov e r th e r e mot e 
cli e nt' s communication link. Because of this significant idl e bandwidth, th e us e r may r e qu e st, a s 
indicat e d at 120, a chang e of mod e from thin - to fat - cli e nt, without int e rrupting us e of th e us e r 
application in thin - cli e nt mod e . That is, th e s e rv e r - bas e d application's "GUI Stat e " can b e 
continuously download e d to th e cli e nt at th e sam e tim e that th e actual application is 
downloading. 

Alt e rnativ e ly, thi s transition from op e ration of s e rv e r - bas e d applications to downloaded 
e xecutabl e cod e , indicat e d at 122, may occur automatically, for e xampl e , upon initial access of 
the serv e r. In e ith e r e vent, according to an e mbodim e nt of th e subj e ct inv e ntion, th e e x e cutabl e 
cod e for th e application may b e download e d as a background proc e ss or thr e ad, p e rmitting 4he 
downloading to take plac e in th e background on th e cli e nt machin e , whil e a thin cli e nt s e ssion of 
th e same application is being conduct e d between the us e r and the application s e rv e r, Thus, th e 
pr e s e nt invention allows a remot e user to hav e virtually instant us e of an application on th e 
s e rv e r, while the executable code for the application itself is b e ing transmitt e d or download e d to 
th e us e r' s cli e nt machin e . Upon download of the application cod e , th e application code may b e 
install e d on the remote user' s machin e . This installation may comm e nce upon prompting to a 
us e r to b e gin the installation proc es s, or th e installation may comm e nce automatically upon 
compl e tion of the download proc e ss. Aft e r installation of th e softwar e , if th e softwar e 
ex e cutable is run by th e user, the us e r will b e operating in fat client mod e , indicat e d by 1 10. 
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Various e v e nts can take place in ord e r to r e turn tho client machine to operat e in a thin client 
mode 1 12. For e xampl e , th e us e r may wish to fr e e up disk spac e or RAM, both of which may be 
fr ee d up to som e e xtent by a mov e from fat to thin - cli e nt. This effect may b e particularly 
desirabl e on small e r capacity cli e nt machin es such as palmtops or PDAs. Alt e rnativ e ly, th e 
cli e nt machin e may p e riodically poll its own s tatu s indicated at 12 4 to sec if a r e turn to thin - 
cli e nt status is n e c e ssary or d e sirabl e , as furth e r indicated at 126 and 128, resp e ctiv e ly. If a 
transition to thin - cli e nt mod e is n e c es sary or desirabl e , th e cli e nt machin e will pr e f e rably ch e ck 
to d e t e rmin e wheth e r communication with the s e rv e r i s pr e s e nt or may b e r e establi s h e d, as 
indicat e d at 130. 

Thin-client mode, as described above, depends on a communications link between client 
and server which is essentially constant in its availability, if the client user is not to experience 
inconvenient delays in execution of input and output feedback. If t e rmination of communication 
with th e s e rv e r occurs or is immin e nt whil e in thin - cli e nt mod e , an imm e diat e transition to fat - 
cli e nt mod e is d e sirabl e if sufficient user application e x e cutabl e cod e has b ee n transmitt e d to th e 
cli e nt machin e . If t e rmination of communication is imminent but has y e t to occur as indicated at 
132, pr e f e rably th e server machin e will download any r e maining us e r application cod e n e c es sary 
for th e application to run on th e cli e nt machin e , as w e ll as any data fil es b e ing modifi e d by th e 
us e r at th e s e rv e r level. If communications are terminated abruptly, preferably the server will 
automatically save any dat a, at 122, file being modified by the client user, as well as several past 
versions, according the client user the opportunity to discard changes saved to the data file. 

An e xample of th e advantages of a combination thin - cli e nt/fat client system and m e thod 
compris e s a user op e rating a portabl e computer in a public location, for e xample, n e ar an airport 
d e parture loung e . In this instance, at a first moment in tim e the us e r is connected to a r e mot e 
communications network, and is operating th e r e latively small memory capacity portabl e 
comput e r or laptop computer or hand held or palm siz e computing d e vic e in the thin cli e nt mod e 
to optimiz e availability of advanc e d programs without th e r e quir e m e nt to dominat e use of the 
remaining available portion of memory in th e local computing d e vic e . How e ver, as the user's 
aircraft boarding time approaches it may be desirable for th e us e r to e mploy s ignal m e an s to shift 
from a thin client mode to a fat client mod e for a s e l e ctabl e portion of an application d e sir e d for 
use onboard the aircraft, but which is not then resid e nt on the user's computing device. This 
sc e nario corresponds to th e "termination of communications immin e nt" branch 132 of th e stat e 
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diagram 108 diagram of Fig. 1. This technology and m e thodology, ther e for e , p e rmits such a 
user to optionally select mod e shifts between the client user mod e s in ord e r to optimiz e not only 
the computing device memory ratio to softwar e utiliz e d but also to tak e into account and to 
accommodat e situational elem e nts which occur e v e ry day worldwid e and which h e r e tofor e hav e 
not b ee n d e alt with in a manner that permits s e amless utilization of th e computing d e vic e in th e 
various situations. In the above example, the user may optionally choos e to r e turn to th e thin 
cli e nt mod e indicat e d as e v e nt 13^1 in state diagram 108, possibly in th e same application 
program, upon arrival at h e r d e stination. 

Public location kiosk typ e cli e nt machin e placement in locations such as airport s may 
incr e as e th e us e r base. For e xampl e , agre e m e nt s may be form e d with major office s e rvic e stor e s 
to f e atur e a s e rvic e based on th e present inv e ntion as a place for a comput e r us e r to stor e th e ir 
fil es for lat e r retrieval at hom e . This pref e rably would r e quire the user to sign - up for an account. 

In addition to p e rsonal databa se s and bu s in es s databas e s, it is possibl e to provide 

collaboration tools, fil e s torag e m e an s , offic e suite programs and oth e r typ e s of d es irable 
packag e s to th e computing d e vic e us e r, such as pr e mium chann e l packag e s. The advantages of 
using the systems and methods described herein include resource savings including financial 
savings, time savings, ready access throughout the world, minimization or eradication of 
synchronization problems in various interface scenarios, improved data security due to a 
reduction in data resident to highly portable and easily lost or stolen portable computing devices, 
enhanced team productivity among multiple users, dramatically improved session persistence of 
users, ready access at one logon or communications step to vast stores of information which may 
have previously required multiple communication access steps and other advantages. The 
experience of a user under this communication system thus duplicates a virtual private network, 
and may be experienced as fully interconnected network 190 of Fig. 4. 

As used herein, office suit e softwar e may includ e but not b e limited to enabling code 
m e ans, word proc e ssing means, spreadsh ee t m e ans, pr e sentation and financial and organizational 
analysi s means, database access and manipulation means, and various combinations of th e above 
and oth e r f e atures suitable for busin e ss or offic e utilization of data and manag e m e nt. 
Collaboration tools used herein includes but is not limit e d to docum e nt sharing softwar e , instant 
m e ssaging software, news and oth e r information projection means, and multiple acc e ss 
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docum e nt s and facilitation software for situations such a s conf e r e nc e s or oth e r projects or uniqu e 
advantag e situation s or opportuniti e s. 

Collaboration m e thods may, in on e e mbodim e nt of the present inv e ntion b e organiz e d 
around us e r - s e l e ct e d themes or projects. For e xampl e , users could defin e a proj e ct as w e dding 
planning workflow which would hav e a screen for e nt e ring th e p e rsons invit e d to th e w e dding, a 
t e mplat e for invitation s , a link to local or national invitation print e rs, a m e chanism for s e nding e- 
mail invitations, an e l e ctronic RSVP li s t, which would automatically ch e ck - off a gu e st wh e n 
h e /sh e has RSVP-ed via e -mail, a link to local wedding venue r e nt e rs, a link to local caterers, a 
list wh e r e th e couple could list th e r e tail establishm e nt s which th e y would lik e to have includ e d 
in th e ir gift r e gi s try. Anoth e r e xampl e is a party planner workflow with an invitation list as 
m e ntion e d abov e , with links to party caterers and links to an automatic map - cr e ation w e b sit e to 
allow th e user to cr e at e a map to th e party sit e which would b e s e nt to us e rs. Another e xampl e is 
a "virtual busin e ss incubator" which st e ps th e us e r through the proc e ss of starting a busin e ss, 
from writing a busin e ss plan, to incorporating, to d e veloping a mark e ting plan, finding an 
accountant or on - lin e accounting softwar e , finding a tax prof es sional, finding sources of funds, 
e tc. Th e re could be links at appropriat e plac e s in th e workflow to corporate attorn e ys, Stat e 
d e partm e nts of comm e rc e , mark e ting prof e ssional s , adv e rti s ing ag e nci e s, e mployment agenci e s, 

Figure 2 is a schematic illustration of a network according to an embodiment of the 
present invention. As depicted in Figure 2, an e-mail or a web page can have a hyperlink to a 
particular application file or document stored remotely on server 142 or remote machine 144. 
The machines form a virtual network linked by the Internet or other communications network 
indicated by network cloud 148. When the recipient or user using client computer 140 clicks on 
or executes the link, information embedded therein directs the client computer to a server 
computer 142 on which a data file and user application reside, a thin-client is automatically 
downloaded to the user, and the application or program associated with the file (typically the 
application that was used to create it, i.e., the data file's native application) is started on a remote 
application server computer 142. The specific file designated by the link is then opened by the 
user application, and the thin-client displays the file on the user's computer 140 within a thin 
client window which contains the application's graphical user interface. The user is then free to 
interact with the file as if it were running inside an application running on the user's client PC 
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140. Alternatively, a remote file on a different remote computer 144 may be accessed by a user 
application running on server 142. 

According to an embodiment of the present invention, a method is provided by which a 
user, e.g. a remote user, may access a remote document in thin client mode, by accessing a 
hyperlink to a URL or network location at which an application accessing the remote file may be 
remotely manipulated and operated. This hyperlink may be referred to generally herein by the 
generic term Application File Hyperlink, or by the name used in trade trad e nam e "AppLink^". 

Figure 3 is a screen view of one embodiment of a computerized method according to the 
present invention. A hyperlink according to the present invention may be created in a GUI 
environment such as that depicted in Figure 3, showing a screen shot 150 of a GUI allowing a 
user to create a hyperlink to a server-supported AppLink. Alternatively, a user may create a 
hyperlink according to the present invention by executing a GUI icon representing the link- 
creating applicatio n, as depicted in Figur e s 3 e and 3f A client user may create a server 
application link by specifying a file resident on a local client machine, e.g., client machine 140 or 
Figure 2, a server 142, or a remote client machine 144 which may establish from time to time a 
direct or indirect link to the server 140. A hyperlink to the server-supported application may 
contain an embedded URL of a server application or protocol which may execute a series of 
instructions to download middleware, or web-enabling client code, to the machine 140 from 
which the hyperlink is accessed. In addition, the hyperlink may contain embedded information, 
or the URL of a protocol file containing information as to the executable code to run on the 
server 140, as well as a particular data file to open within the executable application being run on 
the server 140. This application's output may then be sent as a "picture" by the server 
middleware to a web-enabling client resident on the client local machine 140, as depicted by 
process 630 of Figure 1 . In other words, upon execution of the hyperlink by a remote client 140, 
a process will be executed by the server 142 by which a remote client 140 will have a thin-client 
process loaded onto it, and then access the remote data file, while the native application of the 
data file runs on the server. The remote user interacts with the server application using 
middleware server and client components resident on the respective machines. During thi s 
proc e ss, us e r application e x e cutabl e cod e may b e downloading as bandwidth p e rmits, as indict e d 
by 122 in Figure 1. 
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In a preferred embodiment of the present invention, an originator of a document, in 
creating a server-supported application hyperlink, or AppLink, to a data file such as a 
"document" file, may specify recipient permissions and other access parameters, such as through 
a GUI screen as depicted in Figure 3 as screen 150. In Figure 3, the originator of a document 
AppLink may specify, for example, whether a remote client accessing the document may alter 
the document, selected in pull-down list 151, whether the remote client may save the list locally 
(pull-down list 152), and whether a password will be required in order to access the data file 
being linked (check box 153). In addition, and as depicted in the GUI 150 of Figure 3, the 
originator may specify whether the AppLink through which the file is being accessed will be 
subject to an expiration date (check box 154) or a maximum number of accesses (check box 155) 
and whether the document may be downloaded to a recipient's local computer (check box 156). 
An alternate embodiment of a suitable AppLink origination screen, with corresponding elements, 
is depicted in Figure 3b. 

One advantage of sending this hyperlink to a recipient in an e-mail compared to the 
alternative of simply including the file as an attachment to the e-mail is that there is no computer 
virus danger for the recipient. Many viruses are spread via e-mail attachments, and many 
companies have prohibited all e-mail attachments as a security risk. The thin client software 
required on the recipient's computer can be a "signed" Java applet, meaning that a central 
certifying authority has certified the thin client to be virus-free, and this single program is 
downloaded only once, versus multiple download/run cycles for e-mail file attachments. The 
application file hyperlink is a way to allow an employee of such a company to view and work 
with a file without having to receive the file in an attachment, or download it. Another 
advantage of this method for giving a user the ability to view and work with a file in a server- 
based application is that the originator can then be sure that the recipient will be able to view and 
work with the file, regardless of whether the recipient has a program capable of opening that file 
installed on his or her PC, since a server-based file-compatible application is, in a sense, sent 
along with the file. Viewing a file regardless of the application used to create it is also the 
function of ADOBE'S PDF document format. With PDF, a PDF file is derived from a document 
by a conversion utility. This file is then sent as an attachment or download to the recipient, who 
then views it if he has the PDF viewer installed on his computer. PDF is essentially a "picture" 
of a document, meaning that the recipient cannot change it. With an application file hyperlink, 
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the recipient has full capability to interact with the file. For example, a spreadsheet may have 
several embedded "macros" which would be inaccessible to a person viewing a PDF file. Or, a 
presentation delivered via AppLink can have foil animation and sound. With PDF, a file is 
transferred to the recipient. With AppLink, no file is transferred, and it is not necessary that the 
recipient have a viewer installed on his machine, although he will need a compatible thin client. 
Another advantage is that access to data files of arbitrarily large size can be given to the recipient 
without sending the file itself, and without the necessity of the recipient ever downloading the 
file. Many Internet Service Providers have file attachment size limits of from one to five 
megabytes. An application file hyperlink bypasses that limit, since no file is sent. The thin 
client applet is typically under three megabytes in size. There are emerging numerous file 
conversion utilities and services which will convert various document formats into HTML, and 
display the document to the viewer in the form of a web page. This has the advantage of not 
sending the file to the recipient, but at a cost of removing any functionality from the document. 
This "HTML- Viewer" technique has problems with "multi-paged" files, such as a Microsoft 
Excel spreadsheet with 20 pages. 

Since the file is not sent, the originator of the hyperlink retains control over that data file 
as implemented and controlled in GUI screen 150. The originator of the hyperlink can set 
varying permissions to accomplish various goals. The originator can make the file "read-only", 
meaning that the recipient can view and work with the file but not change it permanently, e.g., 
through pull-down menu 152 of Figure 3. The originator can prevent the file from being saved 
locally onto the recipient's PC, e.g., through pull-down menu 154. This results in the recipient 
being able to view and work with a file in native format, but not possess a digital copy of the file, 
meaning that the recipient cannot copy the file or re-send it to others. Full control of the file 
remains in the hands of the originator, even after the hyperlink has been sent or accessed. In 
fact, the originator can change the file after the hyperlink has been sent, unlike simply sending 
the file itself. For example, the originator can cancel the hyperlink after it has been sent if he 
changes his mind about the message a file may contain. The originator can specify that a 
hyperlink will only be active a specified number of times, e.g., through check box 155. If this 
number is set to 'one', for example, the document becomes, in effect, a self-destructing message. 
The originator can specify that he receive notification each time the hyperlink is accessed, telling 
him that the file has been viewed or worked with, along with data such as the time it was 
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accessed, and for how long. In contrast, under the prior art simply sending an e-mail attachment 
tells the sender nothing about whether the attachment was ever viewed by the recipient. The 
originator can allow the file to be downloaded or prohibit this through checkbox 161 on a radio 
button pair specify that an originator-specified password be required from the recipient before 
file access is granted, e.g., through check box 153 and corresponding text box 158, ensuring that 
the hyperlink is not used by an unknown person. Different passwords could be given to different 
people, allowing the originator to get notification of which person accessed the file. 

In addition to e-mail, a hyperlink could be included on a web page. Clicking on a link on 
a financial adviser's web page might bring up a spreadsheet file within the spreadsheet 
application, with a template for a prospective customer to enter personal information, and 
perhaps run macros to see how much money the financial adviser could save him if he employs 
the adviser. This is much more robust and reliable than simply converting a spreadsheet to a web 
page, since the full functionality of the spreadsheet remains available to the viewer. 

In one embodiment of the present invention, a utility for modifying an application's 
interface settings as specified by a particular file's metadata is provided. The ability to send 
someone an AppLink to a file or to share files online using server-based applications turns 
server-based applications into a means of communication. There is a need, therefore, to modify 
applications for their new communications role. The application interface which the AppLink or 
shared file recipient sees will preferably be optimized for the particular purpose that the AppLink 
sender or file sharer has in mind. 

Figure 3c is a depiction of an application interface selection interface according to the 
prior art. Currently, application interface settings can be customized by the individual, but those 
settings are the same for all documents that person works on. This is depicted in Figure 3C, 
which depicts a common existing Application Interface Customization Interface 170. According 
to an embodiment of the present invention, the ability to associate custom interface settings with 
each file is provided, by means of file metadata. Such metadata can contain the actual application 
interface settings for that file, or user-specified metadata "key words", which point to application 
settings for all files whose metadata contains those key words. Examples of this type of metadata 
might be the key words "presentation for customer" or "document for internal use", etc. Another 
user accessing the file through an AppLink would be limited to the application interface 
specified by the author. Multiple interface settings could apply to a single file, if it is used in 
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multiple ways. Multiple interface settings could be linked to the role of the document at the 
moment, such as "being created or edited", or "being viewed by a customer". These settings 
could also depend on the identity or role of the viewer, such as "document creator", or "viewer". 

An example would be an AppLink to a presentation file, such as Microsoft PowerPoint. 
The file would have metadata which specified that the presentation program presenting the file 
would have only the presentation playing controls, and no editing controls. Another example 
which would use the same interface would be if that file was "shared" with a coworker (not 
AppLinked) for comments, but the creator wanted to reserve making the actual changes to 
himself. Another example would be the removal of "file » save" commands for restricted 
documents. However, the originator of the file would have an interface setting that specified full 
editing and saving functionality. 

The file application interface settings would be stored in the form of file metadata, which 
is normally not seen by the user, but can be created or modified when necessary. The metadata 
could be stored with the file itself or separately in a file metadata database. This file metadata 
could additionally have an additional association with a person or group, so that when that 
person or group opens the file, they get a particular interface optimized for that person or group 
as that general metadata is automatically applied to files that the group member accesses. Figure 
3d is a depiction of a file metadata interface according to the prior art. Figure 3d depicts the 
existing File Metadata Interface 180. 

Altering application interfaces according to file metadata or user role may require 
rewriting the applications to respond to the interface specifications contained in the file metadata. 
However, there is a method to get this capability immediately by "fooling" the applications with 
false users, and using existing application interface modification capabilities. By having the file 
metadata present itself to the application as different users, and then using the application's 
existing interface modification capability to produce different user interfaces associated with 
each false user, it will be possible to use the existing personalization features of many programs 
to achieve different interfaces and functionality, which can then be directed to each user 
according to the user's permissions or security settings. For example, a file's application 
interface may have several optimal interfaces, depending on whether it is used in an AppLink, or 
which user accesses it. Each of those interfaces could be associated with a false user. This may 
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be seen in the following tabl e , in Fig. 6 , showing applicable relationships between file usage, the 
false username associated with a particular interface, and the particular interface requirements. 



"Business Plan. doc" Application Interface Metadata for .doc file 








With These Interface 


File Usage: 


Presented to application 
us inia user. 


IXCC^U 1 1 C 1 1 1C11 1 3 . 


AppLink to 
CapitalCo. 


AppLink_CapitalCo. 


View and window menu 
only. Standard toolbar only, 
with view commands only. 


Fileshare with 
UserA 


FileshareUserA 


All menu and toolbars. 


Fileshare with 
UserB 


Fileshare_UserB 


All menus and toolbars 
except the File menu. 



In this way, the various recipients 5 access to, and control over, the distributed .doc 
document file can be tightly controlled. 

Figure 4 is a schematic illustration of the network of Figure 2, as perceived by a user 
according to the present invention. The present invention, in several embodiments, may be used 
to effect collaborative communications sessions, which may or may not focus on a particular 
computer file that is the subject of the collaborative effort. In this way, the distributed public 
network of Figure 2 may be rendered transparent to the users, to effect a virtual private network 
akin to that depicted in Figure 4. Figure 4 depicts generally a fully interconnected network 190, 
including a document server 142, and various interconnected remote computers, e.g., remote 
computers 140 and 144. The users of remote computers 140 and 144, by accessing a central 
system implementing an embodiment of the present invention, may collaborate by both viewing 
a computer file open on a central server 142, such as an application server as described 
elsewhere herein. Users using remote computers 140 and 144 may both view, edit, and comment 
on a computer file being administered and stored at the central server 142. The location of the 
file is transparent to the user, and the effect of the collaboration as experienced by the users of 
remote computers 140 and 144 is akin to the effect of discussing the application on a centralized 
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virtual bulletin board, where each party may post, react, and watch other users' post their own 
comments and suggested comments. 

Figure 5 is an interface screen capture of a computerized method according to one 
embodiment of the present invention. Figure 5 depicts a GUI screen 210 according to one 
embodiment of the subject invention, suitable for notifying the recipient of an server-supported 
application link as to the status of the data file they may view in thin-client mode as provided by 
the present invention. Upon clicking on a server-supported application link, or AppLink, which 
may preferably appear as a standard hyperlink in an e-mail communication or HTML web page 
as described below, GUI screen 210 is presented to the recipient at computer 146 of virtual thin- 
client network 190 in Figure 4. Recipient user operating client machine 140 may access a 
document stored on server 142, or any other data file residing on a machine of the virtual thin- 
client network collaboration group 190 when such machine is presently linked through a 
communication network to server 142. GUI screen 210 of Figure 5 tells the recipient at machine 
140 the name of the data file, e.g., a "Business Plan" word processing document, as indicated at 
212, the user application to which the data file is native, e.g., "WORD 95" as indicated at 214. 
The GUI screen 210 also indicates the originator of the data file, e.g. "Joe User" at 216. The 
"sender" of the data file corresponds to the data file originator, and this user or registrant 
operates machine 144 in virtual network 190. 

Other data file parameters to be communicated to the recipient are indicated in GUI 
screen 210 including size at 218, and a text box 220 to enter an access password, if required by 
document originator 144 of network 190. The GUI screen 210 may also indicate the parameters 
of access as shown at 222 of screen 210, a thumbnail view or preview of the data file in its native 
application at 224, and whether saving has been permitted by the originator, indicated at 226. 
The recipient of the server-supported application hyperlink may then open the document on 
server 142 of virtual network 190 of Figure 4 by executing the Open button 228 of GUI screen 
210. Downloading or saving to local machine may be effected by GUI button 230, when enabled 
by the document originator at machine 144 in Figure 4. An alternate implementation of a 
suitable GUI is depicted in Figure 5b with corresponding elements labeled. 

In an e mbodiment of th e present inv e ntion implementing a c e ntral customer pr e ference 
and p e rsonalization database, as depicted in figur e 36, a system is provid e d to facilitate th e 
d e liv e ry by multiple v e ndors of customiz e d cu s tom e r servic e s. Th e s e s e rvic es may b e tailor e d to 
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a custom e r's pr e f e r e nces. The service will pr e ferably utiliz e a central databas e of cu s tom e r 
p e rsonal and preferenc e information. Th e s ubj e ct cu s tom e r may pr e ferably be allow e d to 
r e view, add to or change any pr e fer e nces or p e rsonal charact e ristics or int e r e st s p e rtaining to 
their data r e cord, including custom e r clothing s iz es , pr e f e r e nc e s in color and styl e , hobbies, 
inter e sts, prof e ssion, prefer e nc es in food and drink, purchase history, ass e t s own e d, purchase 
information, such as s hipping address and cr e dit card information. A fr ee t e xt ar e a for e ntry of 
fr ee- form information as desir e d by th e customer may be provided as well. Th e ability of the 
subj e ct customer to alt e r data may b e limit e d as nec e ssary to avoid falsification of information 
which may be relied upon by oth e r parti e s, e.g., assets and credit information. A c e ntral databas e 
of th e typ e describ e d would giv e particular b e n e fits to small e r compani es , allowing th e m acc es s 
to custom e r information on a par with th e r e sources of larg e r compani e s. As v e ndors m ee t 
custom e r d e mand in more and more customized and personally tailor e d ways, it may bo 
expect e d that the custom e r's incr e asingly sp e cializ e d interests will b e com e th e province of 
incr e asingly sp e cializ e d, and v e ry lik e ly smaller, compani e s. The principl e barri e r to this 
d e v e lopm e nt is th e cost and effort r e quired to acquir e information about pot e ntial custom e r s by 
small firMs. This central databas e may b e expected to fulfill this n e ed. 

V e ndor s of goods and s e rvices who subscrib e to the central s e rvic e could acc es s this 
pr e f e rence and p e rsonalization information to provid e personaliz e d solicitation, promotional 
information, or services to the customer that pr e f e rably take into account th e custom e r's 
pr e f e r e nc e s. Vendor members may pref e rably b e pr e sented by th e s e rvic e administrator with 
polici e s or rules designed to facilitate custom e r s e rvice and r e duc e th e risk of the abus e of 
custom e r rights. For example, such policies may pr e f e rably includ e at l e ast th e following: Each 
v e ndor, as a condition of access to the data acquir e d by oth e r subscrib e rs, would have to shar e 
what e v e r information it acquir e s on the customer with any oth e r subscrib e r to the databas e , as 
p e rmitted by law and according to th e privacy pr e f e rences of th e subj e ct customer. Such 
information may include, for exampl e , a cu s tom e r' s purchas e history with th e v e ndor, track e d by 
th e us e of a customer unique id e ntifier such as a scannabl e card carri e d by the custom e r, or a 
uniqu e customer user name or ID. In order to furth e r e nsur e th e prot e ction of customer privacy, 
e ach v e ndor might pr e f e rably allow the customer to view any information it had acquired about 
th e custom e r, and to allow the customer to d e l e te it if desired. Preferably th e cu s tom e r would 
not be able to dir e ctly modify information, which is prone to r e sult in its falsification or 



30 



inaccuracy, e .g., cr e dit hi s tory information. Each vendor might b e e ntitl e d, und e r th e t e rms of 
tho servic e subscription, to p e rform its own analys es of th e ba s ic data availabl e on various 
customers, which it may maintain ind e p e nd e ntly without providing th e information to oth e r 
s ubscrib e r s , thu s maintaining each s ub s criber v e ndor' s inc e ntiv e to outdo comp e titors in 
anticipating th e need s of the customer, all to th e benefit of participating custom e rs. 

Figur e 4b is a d e piction of th e g e n e ral data flows betwe e n several groups of e ntiti es 
according to an embodim e nt of th e pr e s e nt inv e ntion. As a further condition of subscription, 
each vendor would pr e f e rably hav e to agr ee to custom e r - s e l e ct e d rul e s regarding how th e 
information is us e d. For e xampl e , a custom e r might s e l e ct that no uninitiat e d contact or 
solicitation may be mad e with th e cu s tom e r. Additionally, a custom e r may preferably sp e cify 
that a limit e d number of contacts per y e ar could b e initiat e d from a vendor, or that any contacts 
pertain to goods or s e rvic e s r e lat e d to th e custom e r' s int e r e st s . According to on e e mbodim e nt of 
th e pr e s e nt inv e ntion, th e s e limit e d numb e r of custom e r contacts may b e put up for bid. The 
v e ndor with th e highest bid would purchas e th e right to contact th e custom e r according to th e s e 
preferenc e s. The proc ee ds could go to th e cu s tom e r, possibly after paym e nt of a f ee to th e 
databas e administrator, thus providing th e cu s tom e r inc e ntiv e to b e com e a participant of th e 
databas e . Companie s sp e nd va s t amounts now to discov e r a custom e r's int e rests and purchas e 
history. Th e r e for e , it may be anticipat e d that thes e compani e s would b e willing to purchas e th e 
att e ntion of customer s that th e y know ar e int e r e sted in th e ir products. Furth e r vendor polici es or 
rul e s that may prove appropriat e are that e ach v e ndor would hav e to agr ee to not r e lease any of 
th e p e rsonal information to any third party without th e cons e nt of, or according to th e pr e f e r e nce 
s e l e ctions of, the customer. A data flow diagram showing on e possibl e impl e m e ntation of this 
e mbodiment of the present inv e ntion is shown in Figure 4 b. Int e raction and data flow between a 
customer group 200, a vendor group 202, and a customer pr e f e r e nc e databas e 20 4 arc indicated. 

Acc e s s to a cu s tomer's personal information could m e an that th e custom e r could get 
p e rsonaliz e d service from a vendor that h e has never patronized before. For example, a cu s tom e r 
that ordinarily patroniz e s one airlin e might purchase a first class ticket on anoth e r airlin e for th e 
first tim e . Ho could b e greeted by the flight att e ndant with his favorit e b e v e rage and newspaper. 
Th e m e al s e rved would be his favorite. Th e flight attendant would know that thi s custom e r lik e s 
to work during flights, and so would not both e r him in - flight. Th ese conv e ni e nces ar e lik e ly to 
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interest c e rtain custom e rs, particularly to th e e xt e nt that th e custom e r i s plac e d in control of th e 
diss e mination of th e r e l e vant information, as provid e d according to a pr e f e rr e d embodim e nt. 

Th e Custom e r Acc e ss Opportuniti es a s limit e d by th e participating custom e r, and as 
g e n e rat e d by a proc e s s shown in Fig. 37, may pr e f e rably be th e subj e ct of a mark e t, arbitrag e 
opportunity, or auction. As e ach v e ndor has agr ee d to customer d e signat e d rul es r e garding how 
the information is us e d, and a customer ha s specifi e d that a limit e d numb e r of total contacts p e r 
y e ar could b e initiat e d from all v e ndor database m e mb e rs, th e cu s tomer contacts afford e d by th e 
information within th e databas e mak e up a scarc e and valuable r e sourc e that may be treated as 
such in a mark e t. Any transactions involving th e cu s tom e r information or contact opportuniti e s 
will pr e f e rably b e in accord with th e custom e r's optional r e strictions on th e v e ndor contacts, 
such as typ e of contact p e rmitt e d, or th e s ubject of contact, as d e scrib e d above. Those limit e d 
numb e r of cu s tomer contacts could b e put up for bid by th e v e ndors, as d e pict e d in Fig. 38 . Th e 
v e ndor with the highest bid would purchase the right to contact th e custom e r. Th e proc e eds 
would go to th e custom e r, subject to a processing f ee . Th e s e proc ee ds may b e in the form -e£a 
cash r e bat e , discount, or credit towards goods or s e rvic e s of a subscribing v e ndor. 

The centraliz e d cu s tom e r databas e may also be enhanced with the provision of valuabl e 

s e rvices to pot e ntial customer s to provid e inc e ntiv e to participat e in th e databas e and provid e 
p e rsonal information to it. Th e s e servic e s would pr e f e rably be related to computing and 
n e tworking, since th e s e s e rvices could b e d e liv e r e d with th e sam e typ e of r e sourc e s that the 
databas e r e quir e s; that is, comput e r s e rvers and n e twork conn e ctions. In a pr e f e rr e d embodiment 
of the subj e ct inv e ntion, these s e rvic es could include acce s s to a us e r's data fil e s and us e ful 
productivity softwar e running on a serv e r and remotely deliv e r e d to th e custom e r via a thin cli e nt 
to any n e tworked computer ho happ e ns to hav e acc e s s to. Th e s e rvic e s could also include th e 
ability for th e user to s e nd AppLinlcs to recipi e nts as described h e r e in. 

In a representative embodiment of the present invention, an application hyperlink may be 
used to implement an intellectual property and confidentiality protection program within an 
organization, providing an effective enterprise-level system for the control and management of 
Intellectual Property and other sensitive information, for example, employee records, medical 
records, or other information the access to which must be controlled or monitored. Under the 
application link made possible by the present invention, and according to an additional 
embodiment, a file control system is implemented by which no file, sometimes referred to 
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generically here as a "document," ever enters or leaves an organization without permission. In 
this embodiment, all internal documents or files are stored in on a central server, and possibly 
encrypted. Accordingly, the native files are not resident anywhere in the organization on local 
computers, and, if encrypted, would be unintelligible if accessed directly. Users can fully 
interact with the documents via thin clients on their local computers. 

The authorized AppLink accesses may be monitored and logged, making it possible to 
determine at any later time whether any accesses were improper in themselves, or were 
indicative of prohibited behavior or misconduct as part of a pattern of access. This may be 
referred to as "prohibitive monitoring". In addition, "encouragement monitoring" may be 
effected, by which all accesses can be reviewed to ensure employees have read critical 
documents such as SOP manuals, policy manuals and procedures, and the like. In a preferred 
embodiment, not merely the fact of a document or file access is monitored, but because the 
screen view sent to a remote terminal may be monitored, a log may specifically track whether 
each relevant portion of a file was displayed for an amount of time consistent with the document 
being read. The application link of the present invention may also provide a document 
management and/or archiving system, by which all documents on the central server can be 
cataloged and searched by author, title, keywords, file numbers, or other relevant fields entered 
for each document. 

In addition to the control of sensitive documents vis-a-vis employees, the application link 
of the present invention is preferably implemented in a manner by which the document control, 
e.g. as part of an IP management system, is extended to outside parties such as contractors or 
investors. Accordingly, in a preferred embodiment of the present invention, the application link 
is paired with an application link e-mail gateway to external parties. The application link e-mail 
gateway is preferably implemented to interface with several popular e-mail, or SMTP 
applications, e.g., Microsoft Exchange. The gateway is preferably configured to be consistent 
with both outgoing and incoming e-mails. The gateway according to the present invention may 
effect security functions in both outgoing and incoming e-mail. With regard to incoming mail, 
preferably all attachments contained in e-mails are intercepted by the application link e-mail 
gateway and stored to a central server. Ingoing message attachments are scanned for possible 
viruses. A dynamically created AppLink, which could be a URL, pointing to the attachment file 
on the server is inserted into the e-mail. The e-mail (without the attachment) is then forwarded 



33 



to the recipient. To view and interact with the attachment via thin client, the recipient clicks on 
the AppLink and the attachment file is opened in a compatible server-based application. 

For outgoing messages, the file security level is retrieved from the file metadata, as 
discussed above, and the appropriate restrictions are added to the application link. The recipient 
clicks on the application link hyperlink and the file is opened with the proper server-based 
application from the application link e-mail gateway server. The recipient then interacts with the 
file via thin client. The present invention assures that no files enter or leave an organization 
without authorization or central control. This is because external users accessing an application 
link only receive screenshots of the file and application. The file itself never leaves the corporate 
network, or preferably, the central server itself Preferably, the application links are created 
automatically, so that end users do not have to change their behavior (e.g., with regard to sending 
attachments), and the centralized control afforded by the present invention cannot be defeated. 
As discussed above, access restrictions and application functionality restrictions can be created 
automatically based upon the file security level contained in the file metadata. This security 
level may, in turn, be tied to the sender's or recipient's job title or security clearance, in addition 
to file-specific criteria. Where multiple restriction criteria apply, the most restrictive choice can 
be made. For example, normally a document might have minimal restrictions, but because it is 
being sent to a potential competitor, access is severely limited 

The central file control afforded by the present invention may be used to effect internal IP 
control and document control. According to the present invention, an organization or individual 
may implement document security in a centralized manner. All sensitive files may be stored on 
one or more central servers. When accessing files, users click on a hyperlink to open the 
document in the proper application. Each user may be granted a security clearance level, for 
example, based upon rank, position, department, or other criteria. In addition to the user security 
level, each file preferably will also have a security level. The combination of the file security 
level and user security clearance level determine which files are available and the user's level of 
access. For example the user may or may not be able to edit, save, save as, print, copy, or the 
like, depending on their access. Similar security classifications may also be effected at the 
directory, or "folder" level. Directories of the files that are available, based upon the user's 
security clearance level or department, may be made available to the sending party, or the 
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recipient or accessing party, to determine the files that the recipient may link to. Therefore, the 
invention will preferably provide for storage navigation tools, e.g., a file manager or the like. 

Preferably, in the event that a recipient does not have proper security classification for a 
document they are sent, a workflow component would be available for users to request increased 
access rights to a document from the sender or from another party with a suitable higher 
clearance level, for example, a supervisor or administrator. 

In a preferred embodiment, efficient document searching is provided by an indexing 
system. Thus, the document library on the central server would be indexed so that a document 
may be searched by author, title, keywords, the permitted actions per security level, and the like. 
The documents in turn may be cataloged by similar or corresponding fields. 

In a file distribution system according to the present invention, no files are ever stored on 
a user's PC or network access device. Instead, users of the AppLink Document Library only 
receive decrypted screenshots of the file and application. The file itself is never stored on their 
network access device / PC. This is linked with a dynamic security model determined by 
combination of file security level and user security clearance level. 

According to one embodiment of the present invention, the Document Library utility 
tracks all accesses of documents. All accesses, both internal and external, may be logged to 
create an audit trail, e.g., in the event of misconduct. This may also be used, for example, to 
ensure that employees read critical documents, or at least that the documents were accessed for 
an amount of time that would admit of reading the document. For example, it could ensure that 
all aircraft mechanics read the latest aircraft maintenance policies and releases. 

For those files and applications for which the user's security admits, files and their native 
applications can be accessed by a central corporate office, a remote office, employees working 
from home, and traveling employees. In all cases, full security and encryption measures are in 
effect, which can be tracked and confirmed, and it may be ensured that derivative copies are not 
created. In a preferred embodiment, it is also possible that the "Save As" functionality of an 
application will not allow the user to create a new file, e.g., a document, that will have less 
restrictive security applications per user security level than the parent file. 

Because the central server is the repository for all files in their native format, all files 
stored on the central server can be encrypted. In addition, all data, such as files, applications, 
and screen views of the remotely running application, that are delivered over the network to 
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users can be encrypted. Delivery of files and applications over the network can be accomplished 
via a middleware environment comprising a middleware web-enabling application, e.g., 
Tarantella or Citrix, and application servers. Preferably, end-users receive primarily or solely, 
the screen shots of the document and application, the application executing on a central server. 
The AppLink security mechanism will interface with existing security approaches including 
existing or future encryption methods, such as PKI, 3DES, AES, or the like. These encryption 
methods may be symmetric or asymmetric. The AppLink security will also preferably be 
compatible with various user authentication or validation methods, including but not limited to 
passphrases, smart cards, token, fingerprint, retinal scan, or other biometric data. 

Each file has metadata associated with it that specifies the security level of the file. Each 
user, in turn, has a specified clearance level. The file security level and the user clearance level 
interact or are compared in order to determine the user's access and privileges with the 
individual file. Applicable application functionality restrictions may include the following: 
read/write, read-only, no printing, no editing, no copying, or various other restriction on 
application functions as applied to the particular file. The restrictions may also be event or time- 
based, e.g., there may be a restriction that a user may access the file a certain number of times, 
view until a particular date. The access may also be based on the access location of a remote 
user, e.g. a user may only access the file from a certain IP address or modem phone number, or 
conversely, may NOT access the file from certain IP addresses or phone numbers. This may 
prevent unauthorized access when authentication information is compromised, or during a duress 
situation, or to prevent applications from being used in countries where export laws prohibit use. 
In addition to business applications, allowing implementing organizations to ensure the 
confidentiality of internal or client projects, the present invention also admits of certain military 
and government applications. For example, the present invention may be used to prevent cases 
of espionage, or the unauthorized access or downloading of files in excess of one's authority. As 
another example, documents may be securely maintained on a central server, thus eliminating the 
problem of a stolen or misplaced laptop, for example, compromising the security of documents 
on the laptop. In the healthcare arena, the present invention may be used to implement the 
patient data protections mandated by the HIPAA statute and regulations. Data may be viewed 
securely by authorized users, without allowing the viewing, downloading, or further transmission 
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of unauthorized patient information, thus aiding in compliance with regulations governing the 
security of individually-identifiable patient information. 

The AppLink system according to the present invention provides for the creation of an 
application file hyperlink (er under the name of trade " AppLink"), which links a remote file and 
a compatible server-based application, generates a link to the remote file/application 
combination, and delivers files via server-based applications to a broad range of recipients of the 
link, including recipients unknown to the sender. Preferably, this access to the remote resources 
may be provided to other users, particularly remote users, with no registration or sign-up 
required of the recipient of the AppLink. According to the present invention, this provides a 
means of communication based on the application and file delivery method. 

One embodiment of a server system that may implement an embodiment of the present 
invention is depicted in Figure 6 1 at 610. Figure 6 1 is a depiction of the process flows in 
creation of an application link according to one embodiment of the present invention. According 
to this embodiment, a local network-connected computer or computing device may serve as an 
interface to a separate server or server array, which may be generally termed the AppLink Server 
602. The AppLink Server 602 may be comprised of a server which operates an AppLink 
Generation Procedure 604, which following file identification 606 and AppLink property setting 
608 accords to the sender's 614 selections, generates at 610 a unique hyperlink designation, e.g., 
a URL location over an IP network such as the Internet, which is associated with (1) a particular 
file or document which is stored on the computer, or a file for which the location is known, and 
(2) a file-compatible server-based application that is the preferred application to be used to open 
the file. This AppLink can then be transmitted by a sender (which could be the AppLink creator 
614) to a recipient by any suitable means 616, including SMTP, BP messaging, embedding a link 
in a web page, or other communication media, even POTS. When activated at 618 by the 
recipient 620, the AppLink connects to the AppLink Server 612, which is periodically polling or 
"listening" for the AppLink' s activation over the network 621 depicted by process 622. While 
the communications are depicted in this embodiment as taking place at least in part in a network 
environment, e.g. 621, other implementations are possible, e.g., dedicated connections or secure 
lines. 

The AppLink Server or Server Array 612 will preferably include an application remote- 
operation enabling middleware program, or application web-enabling program, such as 



37 



Tarantella™ or Citrix™, along with associated application servers running various operating 
systeMs. When the AppLink Server "listener" function 622 detects the activation 618 of the 
AppLink, i.e., the execution of the hyperlink representing the AppLink, it locates the AppLinked 
file, examines the file's properties at 624, and commands the web-enabling program to begin at 
626. This portion of the AppLink Server initially checks at 628 whether the recipient computer 
has a thin client program which can display the server-based application's GUI to the recipient. 
If the recipient does not already have the requisite thin client middleware on his computer, the 
client program is preferably automatically downloaded at 630 and installed on the recipient's 
computer. Alternatively, the user may be prompted to permit or initiate the download, and 
optionally designate a target directory for the download' s local storage. When or if the recipient 
has the thin client installed, the web-enabling program then initiates an Application session with 
the thin client at 632, by commanding a remote application server 634a, b or c of the AppLink 
Server Array to start up a file-compatible software application and load the AppLinked file into 
the application. The web-enabling program initiates a communications link with the thin client 
program at 636 and displays the GUI for the application to the AppLink recipient. The recipient 
620 is then free to view and interact with the file as if it were in a program running on his local 
computer, albeit according to the restrictions placed on the application by the file's owner or 
administrator as set at 608. 

AppLink allows the delivery of files and applications to a much broader range of 
recipients than a normal ASP model which requires recipients to be members of or subscribers to 
a service. AppLink extends the utility of e-mail and the web to software applications. That is, 
AppLink makes it as easy to send an application and a file as it is to send a standard SMTP e- 
mail, or publish a web page. In contrast to application provision of the prior art, the present 
invention provides a new way to communicate by combining the following elements: An 
application file hyperlink, or AppLink, is created to a file which, when activated by a recipient, is 
loaded into a server-based application and presented to the recipient via a thin-client interface. 
In this manner, the file remains on the server, and control of the file is maintained by the sender. 
There is no need on the part of the participant to share Compatible Applications. This is in 
contrast to e-mail attachments of the prior art, in which the recipient needs a compatible 
application on a local computer in order to open the file. In addition to controlling the 
capabilities of the recipient with regard to file access and modification, usage of the file can be 
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tracked by the sender. In addition, the present invention admits of a static AppLink even when 
the document is changed. In other words, the file can be changed at will by the sender, even 
after sending the AppLink, and the recipient will always see the latest version. An attendant 
benefit of the present invention is that the recipient of the AppLink is not exposed to a computer 
virus danger, because the application is running on a remote computer. Only the thin client is 
running locally. This thin client will preferably be either an installed program, or a "signed" 
Java™ applet, wherein a central authority certifies the applet's safety and authenticity. A further 
benefit of the AppLink according to the present invention is that the recipient can immediately 
work with the file without waiting for the file to download, because the subject file remains on 
the server. This is of particular benefit when files are very large, and the recipient is using a 
relatively low-bandwidth connections, say 56 Kbytes/second. According to the present 
invention, a recipient could be working with the file in seconds after receiving and executing the 
AppLink. The AppLink also avoids size restrictions that may be imposed on attachments, and 
generally may be expected in many instances to reduce strain on networks through smaller e- 
mail payloads, particularly public networks such as the Internet that may suffer from "tragedy of 
the commons" inefficiencies. Using AppLink, most files can stay where they are in large part. 
Therefore, the transmission of the entire file is unnecessary and is accordingly eliminated. 

Furthermore, the platform, operating system, or resident applications of the recipient 
machine are immaterial. The recipient 620 of Figure 6 1 could be running on a mainframe, a 
Unix server, a Microsoft Windows server, or other machine with a compatible thin client. 
Because all that is required on the recipient's machine is the relatively limited processing power 
required to run the thin client, the recipient may have virtual access to a relatively vast amount of 
processing capability-the application could be running on various configurations, for example, a 
mainframe, e.g., 634c of Figure 6 J_, parallel multiprocessor machine, or Unix cluster 
supercomputer. In fact, preferably both the sender of an AppLink 614 and the recipient 620 may 
create or execute the AppLink using a networked device with relatively meager computing 
power, e.g., a Web or Internet appliance device, Personal Digital Assistant, Television Set-Top 
Box for cable or satellite television, or any other network-connected or other computing device 
capable of data communication. 

Figure 7 is a depiction of the temporal process in the creation of an application link 
according to an embodiment of the present invention. A typical AppLink "life-cycle" 710 
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according to a representative embodiment of the present invention is depicted in Figure 7, and 
may proceed as follows beginning with AppLink creation 712: The file to be linked must be 
identified by the AppLink sender, herein referred to as the AppLink creator 614. Figure 8 is a 
depiction of the data flows relating to part of the creation of an application link according to one 
embodiment of the present invention. Various potential systems admitting of AppLink creation 
are depicted in Figure 8. AppLink creation paths are depicted generally at 810. This may be, for 
example, the owner of the file, or another party with designated rights permitting distribution of 
the file to others. The application that will open the file must be identified by the AppLink 
Server. A unique AppLink identifier giving the network location of the AppLink data, for 
example, a URL or network location, must be generated. The AppLink data would include, at a 
minimum, the file location. It could also include information about compatible locations 
a pplications , or that could be determined by a software algorithm at the time of AppLink 
activation. At this time, the creator may be prompted for recipient file access and modification 
permissions, and may select a default permissions set according to or derived from the creator's 
permissions to the file, or according to the creator's personal preference default AppLink 
permissions. The creator may be prompted to specify limits on duration or accesses to the file. 
The AppLink properties may include restrictions on all recipients, or on specific recipients. It 
could include restrictions on Recipient Session parameters, such as a limit on the number of 
accesses by a specific recipient; a time limit on any single or a single access session, a limit on 
identified recipient individual session time, or a limit on identified recipient total multisession 
time. Alternatively, the AppLink automatic termination may be based on AppLink Termination 
Criteria, such as an AppLink termination date; a termination time period; a total number of 
accesses reached; or termination if another server-recognizable event occurs. Similarly, 
AppLink usage tracking criteria may be designated and activated. Settable AppLink properties 
pertaining to access tracking may include, but are not limited to, recordation and/or notification 
of: each individual access or given number of accesses; the ID data of each accessor; the time of 
access of one recipient or the consolidated or average access time of a group of recipients; the 
AppLink session time; the file access and/or manipulation details; or the interaction playback of 
a recipient session. 

Settable AppLink properties may alternatively, or in addition, be defined in terms of, or 
depend upon, Recipient Identification Options or Requirements. For example, prior to AppLink 
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access, either at the point of thin client polling, thin client delivery, or file access via the 
AppLink and Application Server, Recipient identification may be required and/or tested, and the 
AppLink session may be terminated if identification fails. Suitable identification requirements 
include, but are not limited to, requirement of a digital signature, for example, that is tested 
against a certificate authority; requirement of a specific IP address set or prohibition of an IP 
address set, which may be down to any level of decimal bit or octet specificity, or of network or 
host specificity; requirement of a password, which may be linked to a user name; requirement of 
http authentication; or requiring an e-mail address and receipt of a confirming e-mail 

Figure 9 is a depiction of the data flows relating to the transmission of an application link 
according to one embodiment of the present invention. Following the creation 712 of the 
AppLink as described above, the AppLink network location, or URL, can be communicated as 
shown at 616 in Figure 6 to a recipient 620 by, for example, and as detailed in Figure 9, 
including it in an e-mail 912, i.e., an SMTP transmission, such as in an e-mail either as a 
hyperlink or hyperlinked graphic, or embedding it in a web page 914, e.g., providing a hyperlink 
or hyperlinked graphic within a web page viewable by the recipient. Other ways in which the 
AppLink may be transmitted to a recipient include communicating it via fax 916, a POTS 
telephone message or page 918 or face-to-face conversation, or any other means of 
communication 920, including surface mail, media broadcast or dedicated line. The user 
interface for creation of the AppLink is preferably implemented as a web-based form generated 
by the AppLink Server depicted in Figure 3 and 3b above. Returning to Figure 8, this web-based 
form 812 is used to communicate with the AppLink Server 602. Alternatively, a native program 
814 capable of creating and/or receiving and viewing AppLinks may be resident and executed on 
the sender's local computer 614, as a part of an e-mail program, as a web browser plug-in 816 or 
a standard feature built into the browser, or as a component of the sender's local computer 
operating system. More broadly, the AppLink creator can use various means to communicate 
with the AppLink Server and create the AppLink. The recipient's thin-client can be made 
accessible to the recipient in various ways. A Java Applet or other download-and-run program 
could be downloaded just before use if the recipient does not yet have a compatible thin client 
available on his local computer. A software company may want to make a thin client an intrinsic 
part of a web browser or operating system, as shown at 818, in order to help ensure that its thin 
client design enjoys wide currency. A company might want to make the thin client a part of the 



41 



circuitry of the client computing device for performance purposes, also helping to ensure that it 
cannot be easily changed by the user to the thin client offered by another company. 

The AppLink executable may also be implemented over the operating system kernel as a 
component or feature of the operating system. At the recipient's end, the thin client may be 
implemented as, for example, a Java Applet or other program downloaded just before first use. 
Alternatively, the executable may be an installed native program optimized for or at least 
compatible with the user's operating system. The thin client may even be implemented as a 
feature, utility, or shell included with a computer's operating system. In an alternative 
embodiment that may be expected to increase the efficiency of the AppLink thin-client, and 
reduce overhead and make the thin-client nature of the file more transparent, the thin-client may 
be implemented in hardware on the recipient's computer 620. This may be expected to provide 
an optimized and very fast thin client. The thin client may also be implemented in multiple 
concurrent ways, preferably designed to be selected according to performance priority rules or 
user preferences as depicted in Figure 10, at 1010, and in Figure 10b. Figure 10 is a depiction of 
the process flows relating to part of activation of an application link according to one 
embodiment of the present invention. Figure 10b is a depiction of the process flows relating to 
another part of the activation of an application link according to one embodiment of the present 
invention. For example, the AppLink Server could look first, at 1012, for a compatible hardware 
implementation of the thin client in the recipient's computer, then for one embedded in the 
operating system, 1012a then for a native application 1012b for one embedded into the web 
browser 1012c, or as a web browser plug-in 1012d, then for one installed as a signed Java Applet 
1012e. If it found none of these, it could initiate a download of a Java Applet Thin Client to the 
recipient's local computer at 1014. Alternatively, an AppLink Server might select a thin client 
based on the creator's restrictions on recipient capabilities. For example, an AppLink Server 
might download and use a Java thin client which has capability "toggles" as described in another 
embodiment of this invention, rather than use an already-installed native client which cannot be 
restricted. 

The recipient of an AppLink such as that of the alternative e-mail formats of Figures 11a 
and 1 lb, following reception, must activate or execute the link at 714, for example, if the link is 
a URL, by clicking on it with a cursor or otherwise executing the link, e.g., by pasting it into a 
browser target address field. The AppLink Server must detect the link activation at 1016, and 
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after confirming that the AppLink is active 1018 poll the recipient's device at 1012 to detect 
whether a compatible thin-client application, applet, or other executable is resident on the 
recipient's computer. If not, a compatible thin client will be downloaded 1020, for example, 
after prompting for authorization and target directory from the recipient at 1022. The AppLink 
server will then initiate at 1024 a thin client session with recipient 620. The AppLink Server 
may then itself, or may direct an Application Server also remote from the recipient, to open a 
file-compatible application, and open the file in the application at 1026. The recipient will 
interact at 1028 with the file through the application user interface, as presented graphically to 
the recipient by the thin client executable. 

The AppLink may be terminated in several ways at 1030. For example, as mentioned, 
automatic termination criteria could have been established by the AppLink creator, such as a 
specified duration. The AppLink could be deactivated by the creator at any time, or the 
AppLinked file could be moved, deleted, or destroyed. Following termination, a recipient 
clicking on an inactive AppLink may, according to the preferences of the creator, be presented 
with an explanatory "AppLink Not Active" message as depicted in Figure 1 lc, perhaps giving 
reasons or expiration information if specified or authorized by the creator, rather than an 
unadorned 404 or similarly uninformative error. 

Figure 1 la is a depiction of a screen view relating to the transmission of an application 
link according to one embodiment of the present invention. Figure 1 lb is a depiction of a screen 
view relating to an alternate manner of transmission of an application link according to one 
embodiment of the present invention. In a preferred embodiment, a system is provided for 
managing and tracking the accesses to an AppLink. For example, a log of AppLink access data 
could be kept by the AppLink server. This may preferably be reviewed by the creator at any 
time, or made available according to the subscription level of the creator. 

Preferably, a system according to the present invention may provide an interface to 
change an AppLink's permissions at any time after creation, for example, by extending a "drop- 
dead" time. Figure 36 44e is a depiction of a user interface screen capture relating to an 
unavailable link according to an embodiment of the present invention. 

Following termination, a recipient clicking on an inactive AppLink may, according to the 
preferences of the creator, be presented with an explanatory "AppLink Not Active" message as 
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depicted in Figure 36 44e, perhaps giving reasons or expiration information if specified or 
authorized by the creator, rather than an unadorned 404 or similarly uninformative error. 

Figure 12 is a depiction of a process flow relating to the creation of a guest account for 
access to application link according to one embodiment of the present invention. As depicted in 
Figure 12, the recipient of an AppLink will preferably be granted access to a temporary guest 
account created upon execution of the AppLink at 1212, following AppLink execution 1210. 
Alternatively, multiple guest account may be created in advance and assigned to specific 
AppLinks as they are activated. The AppLinked file may be copied from server-accessible 
storage at 1216 into the guest account 1218, and a compatible application may then open the 
copied file in the guest account. The creation of guest accounts for AppLink recipients may be 
expected to create a more secure system than the alternative of opening the AppLinked file 
within the account of the sender, with restrictive "guest" file access permissions, as depicted in 
Figure 39, although this alternative can be advantageous for collaboration since it facilitates the 
AppLink sender viewing a document altered by a recipient, because it is contained in his 
account's readily accessible data storage. Since AppLinks can be transmitted to a broad range of 
recipients, some of whom might not be known to the sender or particularly trusted, security is 
vital. Accessing an AppLink with a "dummy" user account rather than directly from the 
AppLink creator's account (with file access restrictions, of course), the damage which an 
unscrupulous, "hacker" AppLink recipient could do may be restricted. For example, there would 
be no way for such a recipient to access or delete other files contained in an AppLink sender's 
service account. The temporary guest account may be automatically deleted 1220 upon 
termination of the session 1222. 

A system implementing the present invention will also preferably permit encryption of 
the AppLink locator link prior to transmission to the recipient. In fact, the AppLinked program 
may itself be an encryption/decryption program. A suitable scheme for implementation of 
encryption is shown in Figure 13. Figure 13 is a depiction of process flows relating to the 
encrypted transmission of an application link according to one embodiment of the present 
invention. This would allow various items to be encrypted prior to being sent to the recipient. A 
recipient could be sent the encryption program URL, plus a password to access the encryption 
program, and/or a key to decrypt and encrypt files with the AppLinked encryption program. 
Then the recipient could be sent multiple encrypted files either as an AppLink to an encryption 
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program that has file access to encrypted files, or as an e-mail attachment or via FTP, and could 
use the AppLinked encryption program to decrypt and view the files. Or the recipient could be 
sent encrypted AppLink URLs or AppLink passwords, and could use the AppLinked encryption 
program to decrypt the AppLink or AppLink passwords. In this manner, the present invention 
allows a single insecure transmission of a password to the recipient, who could then use it to 
decrypt and view files or AppLink URLs or AppLink passwords. The earlier described 
advantages of the present invention accrue to this embodiment as well, i.e., ensuring that the file 
is compatible with the program. In this case, both the decryption program and the program used 
to view an encrypted file are assured to be compatible with the encrypted file. 

The present invention may also be implemented via an AppLink creator's own Internet- 
connected computer, with the creator's machine performing the functions of an AppLink Server 
and Application Server. In order for this implementation to be transparent to the recipient, this 
computer will preferably remain connected to the network at all times. Accordingly, ISPs and 
website hosting services, as well as entities or individuals maintaining their own internet servers, 
may in many cases implement this capability almost immediately. In the situation in which an 
AppLink incorporates a file not resident on the AppLink Server, e.g., the file is stored on a 
different Network-connected computer or data storage device than the AppLink Server, the 
AppLink Server preferably will record the location of the file at the time the AppLink is created, 
and will use a system to open it from that location, or it will upload a copy of the file to the 
AppLink Server. Preferably, an Application Server must be able to access the file being 
AppLinked in order to open and run it within an appropriate server-based application. If it is not 
stored on server-accessible data storage, the file must be capable of being opened from its current 
location, or uploaded onto the Application Server prior to the file being loaded into the AppLink 
application. 

While in a representative embodiment of the subject invention, an AppLink is provided to 
a particular file native to an application, the present invention also permits of an AppLink to a 
specific application program rather than to a particular file. An AppLink to an application would 
allow the recipient to use the server-based application to create a new file, or just try it out, 
perhaps as part of an application demonstration. When combined with some sort of "Metafile 
System" as described h e r e in , this would allow a user to aggregate applications together 
regardless of their source, perhaps from different vendors. 
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A single AppLink may be hyperlink to a number of different files, such as a group of files 
relevant to a project. Suitable ways of implementing a multiple file AppLink include but are not 
limited to the following: A multi-file AppLink could simply bring the recipient to a web page 
that then has multiple links, one for each file. The recipient would then click on each individual 
link to view each file. Alternatively, a multi-file AppLink would open each file in its own 
application window all at once when it is activated. In yet another embodiment, depicted in the 
flow diagram of Figure M 28, a computer GUI "desktop" style interface is sent, rather than a 
particular file. The desktop-style work area may contain links to the relevant files within that 
GUI desktop. The linked "Computer GUI Desktop" work area, could be, for example, a 
Windows Desktop or a Linux Gnome or Linux KDE Desktop. In a more specific embodiment, 
the AppLink Server may link to a web-enabled "Computer GUI Desktop" which contains access 
links to a specific file or files and to file-compatible applications, the AppLink is a link to one or 
more files in a Desktop. This embodiment of sending a file or files within a GUI desktop makes 
possible links that would otherwise be impracticable. For example, with some programs, such as 
Adobe Photoshop™ or the Linux GIMP image editing program, the program works with multiple 
windows, which can be minimized, moved, and resized, and serve various specialized functions, 
for example as tool and color palettes. Multiple windows cannot readily be web-enabled by 
existing web-enabling applications. Also, those web-enabling applications have some limitations 
on window sizes. For example, the Tarantella™ web-enabling application does not have 
infinitely resizable application windows for Microsoft Windows applications; it is limited to 
fixed, preset application window sizes (such as 800x600) as set by the Tarantella administrator. 
However, if Tarantella is used to web-enable a GUI desktop, then within the desktop any 
application windows are infinitely resizable. Also, all the advantages of a GUI desktop then 
become available to an AppLink recipient. For example, the Linux Gnome or KDE desktop has 
"virtual desktops," which extend the working area of the user's screen up to 32-fold. An 
application that is web-enabled directly, rather than within a GUI desktop, will typically have a 
working area limited to the application window size. 

In Fig. 34 28, at an appropriate point in the AppLink creation process 3501, the creator is 
presented with choices on how to present the files and applications. As indicated by 3502, he 
may create a completely new "guest" desktop 3508, or use one that he has already created. Such 
a guest desktop will have a completely separate data storage account, but one that the AppLink 
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creator may populate by moving or copying files to and adding links to applications, as in 3503. 
He may then create an actual AppLink or network address or URL at 3504. Yet another 
alternative approach is shown in 35 12, which is tantamount to giving a user access to your entire 
computer desktop, but with restricted permissions 3513, for example read-write permission only 
on the file the AppLink creator wishes to collaborate on, and no read permission for any other 
file. Alternatively, after deciding that a file or series of files would be best presented to a 
recipient in a guest desktop 3509, the AppLink creator may want to have the guest desktop 
automatically created for him, as shown in 351 1. Or he may decide that a simpler "multiple file 
AppLink" 3510 would be more appropriate, wherein each file is presented to the user in a 
dedicated application window 3515. After the creator has decided on a method of file and 
application presentation, the AppLink is transmitted 3505, and the recipient clicks on it 3506. 
The AppLink Server starts running the appropriate GUI desktop in an application server, in this 
case a Linux server, since the desktop depicted 3508 is a Linux Gnome desktop. This desktop is 
delivered to the recipient via a thin client 3507. 3514 depicts the overall process of selecting the 
mode of file-application presentation. 

In another embodiment of the present invention, the ability to create an AppLink to a 
computer "GUI Desktop" which is running on a remote application server allows that desktop to 
be used as a Web Portal Home Page, as shown in Figure 33 43-. This "GUI Desktop" 4301 could 
preferably include one of the open source Gnome or KDE desktops for Linux, since the required 
code is open to public access and free of charge, or one of the Microsoft Windows desktops (win 
95, 98, Me, 2000, etc). 

Personalized "home" pages, an example of which is shown in 4302, as generated by 
major web portals such as Yahoo™ have evolved over time to contain various features, including 
personalized news, weather, stock quotes, email, an instant messenger application, calendars, and 
file storage . These functions, although generally well designed, are limited by the functionality 
of the various web page languages such as HTML and JavaScript. If an entire web page refresh 
is not to occur every time a viewer initiates an action, JavaScript or it's equivalent must be 
written into the page itself to anticipate such an action and have instructions for generating a 
response. It is impossible to write into a web page with Javascript the full functionality of a 
standard software application. Therefore, these web page functions are limited in functionality 
and poorly performing compared to native software applications. Also, generally a web page is a 
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static thing, with the content unchanging until a user initiates a web page "refresh". With a 
(probably password-protected) AppLink to a computer's "GUI Desktop" work area, all of these 
limitations can be overcome. Applications can be fully-fledged programs, such as the Microsoft 
Outlook™ email program, rather than glorified web-based forms. Current events can be streamed 
to the user real-time by the program without refresh. Plus the Desktop can run major applications 
which have no HTML equivalent. The desktop can be customized by the user to a far greater 
extent than can the HTML version, as can be easily seen in Figure 33 44. 

There will often be a need to change the document or file associated with an AppLink 
after the link is created. Figure 14 is a depiction of process flows relating to dynamic changing of 
file accessed by an application link according to one embodiment of the present invention. 
Because the AppLink is server-based, it can be changed anytime, and the person viewing it 
always views the latest version. According to the instant invention, there are provided multiple 
ways to change the AppLinked file associated with a particular already-created AppLink, 
without changing the AppLink network address, exemplary ways being depicted in Figure 14. 
One is to change the contents of the file without changing the file name, as shown by 1402 and 
1405. Another is to change which file is associated with an AppLink after the AppLink has 
been created, i.e., a different file can be associated with a previously-generated AppLink URL or 
address after the AppLink has been created, as in 1401 and 1404. This would be useful when 
getting the AppLink into the hands of its intended recipients is expensive or time-consuming, or 
when the sender does not know who has received an AppLink. 

An example of this would be the case where a number of people (unknown to the 
AppLink creator), after viewing an AppLink embedded in a web page, have added an AppLink 
URL to their web browser bookmark list. It would be impossible to send a new URL to these 
people. Similarly, a web-based newsletter publisher could send a single AppLink to his 
subscribers, instead of sending the subscribers a different AppLink every month. Each month he 
would associate that AppLink with a different document, that is, the latest newsletter, as depicted 
by 1401 in Figure 14. He could cascade down the files associated with each AppLink, and label 
them accordingly. For example, the AppLink labels could be "current month's newsletter", "last 
month's newsletter", etc. In addition to dynamic file which can be accessed in their current state, 
the present invention also admits of a snapshot embodiment, by which a recipient may be 
presented with a file as it existed at a particular time in the past, even if the master file has been 
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changed during that time. This embodiment is shown at 1403 and 1406, and is further depicted 
in Figure 15. Figure 15 is a depiction of a process flow relating to a file presented as static 
accessed by an application link according to an embodiment of the present invention. 

Preferably, the AppLink utility of the present invention will provide settable variables, by 
which the AppLink sender or creator has the ability to set and change conditions associated with 
an AppLinked file (for example, file access and usage permissions), or any other variable (for 
example, the degree to which the AppLink usage will be monitored), for example, to facilitate 
protection of the AppLink creator's intellectual property (the AppLinked file). This ability to 
attach various conditions or enable various features for AppLinks is a central advantage that 
AppLinking has over other file transmission and access systems. The settable variables may 
depend on other criteria as well, by which any Settable AppLink Variable may be set and varied, 
for example, according to the specific identity of the recipient or the nature of the file, or whether 
the recipient is a member of a specific group of users, the recipient's location or country, as 
identified by his IP address, or any other relevant criteria. AppLink notification properties may 
be set as follows: The sender may be notified or not, and if notified, notification may be 
effected, for example, by e-mail/SMTP message, computer instant message, POTS call, voice 
mail, or pager alert. The notification may include access details as to recipient, access password 
used, time or occurrences of access, or the like. 

AppLink restrictions on recipient actions may include the following: allow (or disallow) 
local printing; screen capture/print; local file save; AppLink server file save (modify base 
document); or allow/disallow local download. The settable variables may involve one or more of 
the following AppLink or file attributes, which may vary according to the degree of trust placed 
in the recipient, whether all recipients are known, the degree of sensitivity of the file, and the 
like. For example, variables may involve printing—the recipient may be allowed to print the file 
locally, in the case of a trusted recipient, or for an untrusted recipient, no printing is allowed. 
Similarly, the recipient may be allowed to use the "Print-Screen" capability of the local PC to 
print a screenshot of the file locally (trusted recipient) or not (untrusted recipient). The recipient 
may or may not be permitted to save the file locally or copy to a PC "clipboard" or similar 
memory utility. This ability to prevent saving and printing may be expected to enhance the 
ability of the AppLink creator to protect any intellectual property or security of the AppLinked 
file by restricting copying and redistribution. In addition to setting restrictions on local saving of 
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the AppLinked file, the creator will also preferably be able to specify whether downloading to 
the recipient's machine is permitted. This may be distinguished from the saving variable 
discussed previously, i.e., saving from the server-based application. When downloading is 
enabled, a link to a simple file download utility may be permitted. Downloading a file and 
opening it with an application running on the AppLink recipient's local PC is for many purposes 
inconsistent with the AppLink system. However, this download option will ensure file 
accessibility, as a backup system, if the sender was uncertain about whether the recipient could 
operate the required thin-client, perhaps due to the recipient being behind an incompatible 
firewall, or the recipient possibly accessing the AppLink from a computing device that has no 
thin client support at the time. The download capability would ensure that the recipient would 
get the file, albeit at the cost of losing control of it, and losing the certainty of whether the 
recipient could open it in a compatible application. Therefore, the AppLink creator would have 
to balance the need to ensure the AppLink recipient gets access to a file with the requirement to 
retain control of a file. Naturally, this option would only be given to trusted AppLink recipients. 
Other variables include the capability to Save Changes onto the AppLink Server, i.e., whether 
the AppLink recipient may change the document permanently and save the changes on the 
server. This may be among the variable settings "read-write" permissions to a trusted recipient, 
or "read only" permissions to an untrusted recipient. 

Restrictions and other characteristics associated with a particular AppLink as outlined 
above can be implemented at the time of AppLink creation or at any time thereafter via a series 
of AppLink "properties". As shown in Figure 30 40, these options could be presented to the 
AppLink creator at the time of creation as a series of questions, as depicted for intellectual 
property protection 400 land access notification 4002, and in Figure 3 0B 40B for recipient 
identification options 4003 and usage tracking 4004, and for recipient session limits 4005 and 
AppLink termination criteria 4006 in the flow diagram of Figure 3 PC 40G. At the conclusion of 
the property setting phase of AppLink creation, the process 4007 will record the results, associate 
them with the created AppLink, and continue the creation process. 

AppLink properties would be set initially as a "best guess", probably most restrictive, 
configuration. The AppLink creator would modify these properties during the first creation 
process, and any modifications would then be implemented automatically for subsequent 
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AppLinks. Additionally, the AppLink creator may modify the properties of existing AppLinks at 
any time. 

A method to implement AppLink recipient restrictions may be provided which may be 
termed Thin-Client "Toggles," these are depicted in Figure 16. Figure 16 is a depiction of 
process flows relating to the control of client capabilities for an application link according to one 
embodiment of the present invention. This may be thought of as a "catch-all" access control 
variable. Because the thin client is the vehicle by which the application interacts with the 
AppLink recipient's local computer, some settable AppLink Variables, including recipient file 
permissions, can be done by building in APIs into the thin client termed "toggles" herein, which 
allow certain capabilities to be toggled on or off remotely by the AppLink Server. According to 
this variable, the thin client has built-in software "toggles" or APIs, which can be controlled 
remotely by the AppLink Server. These "toggles" control the recipient's local capabilities, 
including but not limited to the variables that have been discussed above, such as local file 
printing, save to local memory or "clipboard", save to local storage, or saving file changes onto 
the AppLink Server. Such toggles could be set by the AppLink server according to file 
permissions, recipient permissions, or both. These toggles may also be set or changed following 
the initial AppLink transmission, according to changed circumstances, by the AppLink creator. 
The toggle capability of an embodiment of the present invention is depicted in process flow 
diagram of Figure 16, indicated generally at 1610. As shown, after an AppLink is activated 714 
by the recipient, the AppLink server may examine the scheduled or specified properties of the 
AppLink at 1612. Following this assessment, the server-based application may be started on the 
Application Server as indicated at 1614. Approximately concurrently, the specific AppLink 
properties at 1616 are examined, in this instance that printing and local save will not be 
permitted, but a local memory "clipboard" copy will be permitted, indicated at 1618. The 
appropriate functions are then disabled, from the perspective of the user, as indicated at 1620, by 
acting on the recipient's thin client. The appropriate restrictions on the recipient user's 
capability are implemented in the thin-client environment, indicated at 1622. 

As an alternative, the actual implementation of some settable AppLink Variables, 
including recipient file permissions, can be done through interacting with "toggles" or APIs to 
the on-line application that opens the file, as depicted generally in the flow diagram of figure 31 
4+. An AppLink is activated by the recipient 4101. The AppLink Server 4102 examines the 
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AppLink properties 4103 or recipient properties for any restrictions on recipient access. If that 
application has no "print" capability, perhaps through deleting the "print" command from the file 
menu by activating a "no print" software "toggle", as shown in 4104, then the AppLink recipient 
cannot print locally as shown by 4106, even if the thin client 4105 otherwise has the capability to 
let the application do so. This is a very specific instance of the more general, "Application 
Interface Specified by File Metadata" embodiment. This is very similar to the flow for thin client 
"toggles". 

As a third alternative, rather than changing the toggles of the thin client environment as at 
1610, the toggles may be implemented so as to act on the Application Server directly. The thin 
client then functions normally with full functionality, and does not effect the disablement of any 
feature or function. Since the AppLink Server is the middleware that transmits data from the 
application servers to the thin client, a way to implement restrictions on AppLink recipient 
capability is to use the AppLink Server to not allow a prohibited function to be transmitted from 
the server-based application to the application or thin client. 

In addition to application or thin client software capability "toggles", another way to 
achieve the same capability of limiting an AppLink recipient's file permissions is through 
Application Versioning, i.e., to create different versions of the thin cli e nt or application that have 
varying capabilities. Figure 17 is a depiction of process flows relating to an alternate manner of 
control of client capabilities for an application link according to one embodiment of the present 
invention, showing a typical implementation of such a process. For example, if an AppLink 
recipient should not be able to print an AppLinked file, the specific thin client or application 
version downloaded would have this capability deleted. This procedure is indicated generally at 
1710. The AppLink may call different versions of a thin client or on-line application which have 
varying capabilities for interacting with or manipulating a file. For example, application 
versions without certain key command menu items, such as "print", "save", or "copy" may be 
created prior to AppLink activation, and specified as the application that should be used to open 
the file upon AppLink use. For example, as depicted in Figure 17, following activation of the 
AppLink at 714, the AppLink Server Array may examine the creator-specified AppLink 
properties at 1712. Based on these specifications, the server-based native application is selected 
that has functions corresponding to the specifications. In this example, native application "A" v. 
3 is selected at 1714, which provides the appropriate functionality that the recipient can neither 
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print, save locally, copy to the clipboard, or edit the file, per the specifications examined at 1712. 
The commands otherwise included in the application user interface may be "greyed out," or 
omitted entirely. The thin client passes on at 1716 all of the functionality provided by the 
application version selected at 1714, which in this case is limited. Similarly, specific Thin Client 
versions could be created that disable or omit the capability to print locally, or to access local 
storage of the AppLink recipient's local machine. The specific version of thin client or 
application (or both) chosen by the AppLink Server to present an AppLinked file would be based 
on the AppLink recipient file permissions, as set by the AppLink creator. 

In a furth e r e mbodim e nt of the pres e nt inv e ntion, variabl e color depth or other variation 
in resolution is provid e d for th e thin cli e nt bas e d on th e bandwidth and/or data tran s mission 
sp ee d of th e conn e ction that the thin cli e nt machin e maintain s with the central serv e r. According 
to this embodim e nt, th e number of colors per pixel (color d e pth), and oth e r display r e solution 
param e t e rs, us e d in a comput e r' s thin cli e nt display (which displays th e r e mot e application' s 
GUI) is varied or controll e d automatically, bas e d upon th e s e rv e r - m e asur e d bandwidth or data 
transmission sp ee d b e tw ee n th e application s e rv e r and the thin cli e nt, or both in combination. As 
th e valu e of m e a s ur e d bandwidth is incr e as e d, a higher number of colors could b e us e d by th e 
display without aff e cting p e rformanc e as p e rc e iv e d by th e user. Th e m e asur e m e nt of bandwidth 
could be done initially upon b e ginning a thin cli e nt s e ssion, to e stablish th e scr ee n r e solution for 
th e e ntir e s e ssion, or continuously or at intervals throughout th e s e ssion to provide the thin cli e nt 
us e r with the best scr ee n imag e /p e rformance combination. If th e data transmission time b e tw e en 
th e s e rv e r and th e thin client incr e as e s, th e number of colors per pix e l could b e r e duc e d to reduc e 
th e amount of data flow. Th e monitoring of data transmission tim e , or latency could b e don e 
initially or continuou s ly or at int e rvals throughout th e se ssion, but preferentially continuou s ly or 
at short int e rvals du e to data lat e ncy's greater varianc e ov e r time than bandwidth. An incr e ase 
abov e a c e rtain "thr e shold" lat e ncy would cause colors to be r e duc e d in ord e r to r e duc e th e 
lat e ncy tim e . In a pr e f e rr e d e mbodiment, this color or other display resolution may b e manually 
s e l e ct e d by the thin client us e r in the event that the user perceiv e s that th e p e rformanc e of th e 
thin cli e nt display is lacking, e .g., there is an obtrusive time d e lay b e tw ee n th e ir input and th e 
r e flection of their input in the thin cli e nt display. 

Us e r perceiv e d performanc e is th e r e action of the application to the user's inputs to the 
thin cli e nt. Th e user's input (such as typing a k e y) must be sent from the thin cli e nt to th e 
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application s e rv e r, then the s e rver must r e fl e ct that in the application (th e l e tt e r must b e 
impl e m e nt e d in th e application e nvironm e nt), th e n the new scr ee n imag e or portion ther e of must 
be sent to th e thin client. When this cycl e b e com e s notic e ably long, the perceived performanc e 
is degrad e d in th e e yes of th e us e r. This cycl e i s determin e d by two factors: Bandwidth and data 
transmission sp e ed or lat e ncy. Bandwidth is th e amount of data which can b e transmitted in a 
certain tim e p e riod. It is typically measured in kilobytes p e r second. Transmis s ion speed or 
latency i s th e tim e data takes to g e t from point to point, in this cas e from the serv e r to th e thin 
client. Bandwidth varies over th e time of a thin client r e mote application s e s s ion, but typically 
not by a larg e p e rc e ntag e . Transmis s ion lat e ncy can vary dramatically, however. 

Th e numb e r of colors for comput e r displays ar e typically powers of 2 which ar e r e f e rr e d 
to as "bits". Common numb e rs of colors arc 16 (2 A 2, or 2 - bit), 256 (2 A 8 , or 8 - bit color, also 
known as Vid e o Gate Array, or VGA), 65,536 (2 A 16, or 16 - bit, also known as hi - color), and 16.7 
million (2 A 24, or 2 4- bit color). Going from 8 - bit color to 16 - bit color means doubling th e 
amount of image data. Example: At a scr ee n siz e of 6 4 0 pix e ls x 4 80 pix e ls, th e scr ee n imag e 
has 307,200 pixels. One byte equals 8 bits. At 8 bits (or 1 byte), the image requires 307,200 
byt e s, or 307 kbytes (Kb). At 16 bits (or 2 byt e s), th e image requires 61 4 , 4 00 byt e s, or 61 4 Kb. 
At 24 bits (or 3 byte s ), the imago requires 921,600 byte s , or 921 Kb. 

Th e s e charact e ristics l e nd th e mselves to a two - stag e optimum color d e pth calculation as 
depict e d in Figure 18. Figur e 18 is a depiction of proc e ss flows r e lating to a dynamic cli e nt 
display according to on e e mbodim e nt of th e present inv e ntion. Initially color d e pth may b e s e t 
bas e d on the bandwidth as indicat e d g e n e rally at 1810. Th e n a s indicat e d g e nerally at 1 8 20 
lat e ncy may be monitored, and depth e ither reduced or incr e as e d as at 1822 in an inv e rs e r e lation 
to th e m e asured latency. In oth e r words, if mor e lat e ncy is obs e rv e d, a low e r color depth is set. 
Th e scr ee n image is a larg e part of th e data which is sent to the thin client. Incorporating 
bandwidth in addition to latency, as shown g e n e rally at 1830, if th e bandwidth to th e cli e nt is 
limited a s measured at 1 8 32, or if data transmission speeds are limit e d as indicat e d by 183 4 , 
b e tt e r us e r p e rceived p e rformanc e can b e achi e v e d if th e amount of data in that imag e is low e r- 
A s a g e n e ral proposition, latency l e vels of approximat e ly 200 millis e conds round trip (pressing 
the key and s ee ing th e l e tter app e ar) ar e perceptible to users. Abov e this l e v e l, r e ducing th e 
color d e pth at 1836 in order to achi e ve low e r lat e ncy tim e s will r e sult in a l e ss obtrusiv e lat e ncy 
timer 
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If, due to changed circumstances, or otherwise at the discretion of the AppLink creator 
and/or file owner, it is desired to further restrict the access to a file associated with an already 
created and sent AppLink, the AppLink creator or sender can inactivate the AppLink after it has 
been sent. AppLink inactivation may also be done automatically, i.e., the creator or sender can 
have the AppLink Server inactivate an AppLink automatically according to an expiration 
condition or criteria. Example criteria might be, but are not limited to, the following: The 
passage of a specific time period, a specific date, a specific number of total accesses to an 
AppLink for all AppLink recipients or for a particular recipient, or the occurrence of some (any) 
event which can be recognized by the AppLink server, or which the AppLink server can be 
notified of via external input. The AppLink creator or sender may alternatively set a limit on 
AppLink file access time, either by individual session, in total, or both; for all AppLink 
recipients or for a particular recipient. For example, to protect intellectual property, the AppLink 
session could be limited in time, thus not providing the recipient with sufficient time to copy the 
information by hand. Normally, this limitation would be associated with allowing the recipient a 
single AppLink access, otherwise, the recipient could simply access the AppLink multiple times 
to allow sufficient access over several sessions. Or, if the total session time were limited, then 
the number of accesses would be irrelevant, since the time of access for each session would be 
added to that of previous sessions until the limit is reached. 

According to the present invention, an AppLink is capable of being used in an 
anonymous mode, that is, unknown users can be given access to applications and files, as where 
an AppLink is published in a web page. However, because the AppLinked file remains on the 
AppLink server, using AppLinking for file transmission or communication can protect the 
sender's Intellectual Property or other confidential information (the AppLinked file) from being 
appropriated in unauthorized ways, IF it is combined with the ability to restrict access to an 
AppLinked file to authorized recipients. The authorized recipient could be identified by various 
systems, including requiring entry of a recipient's name, a particular password, a digital 
signature, or an e-mail address that is authenticated to prevent spoofing. For example, after e- 
mail entry, a password could be e-mailed to the recipient's e-mail address to ensure that the e- 
mail address is valid. Similarly, a particular recipient could be restricted to accessing the 
AppLink from a particular IP address. An AppLink recipient may also be required to perform an 
action or give certain Sender-specified information via a web-based form or a server-based 
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application (such as spreadsheet or database data entry template) in order to gain access to the 
AppLink. For example, the recipient may need to give their name and address, or authenticating 
information such as answers to specific questions posed by sender, as depicted 210 in Figure 5b. 
This action or information entry may also be made optional by the AppLink creator. 

While an AppLink is capable of being used in an anonymous mode, the AppLink sender 
may want to restrict access to a file to one or more particular individuals, and may want to track 
that individual's usage of a file. That recipient could be identified by giving the recipient a 
unique password, which is linked to the recipient's name by the AppLink Server. In one 
embodiment of the present invention, the AppLink creator may link a password to a particular 
entity, e.g., a natural person or company, etc., which then allows the sender to identify the use of 
the AppLink by that entity. When the password is used to access an AppLink, the user knows 
that it is probably the entity he sent the password to that has accessed the AppLink. For 
example, the AppLink sender associates the password "XXYY" to access a particular AppLink 
with John Smith. The sender then transmits the password to Mr. Smith. He associates the 
password "1 122" to access the same AppLink with Mary Jones. Someone accesses the AppLink 
using password "XXYY". The sender can therefore be reasonably sure that it was Mr. Smith, 
even though the access was otherwise anonymous. 

Other authentication methods may be implemented according to an embodiment of the 
present invention, as depicted at 4003 in Figure 30b . For example, the recipient may enter a 
password to the AppLink Server prior to AppLink access via the HTTP authentication protocol. 
A Recipient Digital Signature may also be used, wherein a particular recipient must be identified 
by the AppLink Server by their valid and unrepudiated Digital Signature prior to AppLink 
access. Identification of an AppLink Recipient may also proceed by restricting access to an 
AppLink to certain recipient IP or IPv6 addresses, or other suitable network location indicia. 

In an alternate embodiment, as depicted in Figure 18, a software algorithm may be 
implemented to select the appropriate application to open a file within an AppLink, based on 
appropriate criteria, which could include but is not limited to: recipient ownership of application 
user rights to possible application choices; any license agreements for possible application 
choices including but not limited to end-user agreements and service provider agreements; and 
application file compatibility, or which file types possible application choices can open. When 
an AppLink is sent to a recipient, the selection of the server-based application to open the file 
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depends on server-based application software license terms. Many end-user software license 
agreements contain the limitation that it cannot be used by more than one person at a time, thus 
losing potential sales. If a user sends an AppLink which requires an application which has such 
a license, one way to comply with that license provision is to ensure that the recipient has the 
right to use that application also. Before the application is presented to the recipient, if the 
algorithm had access to an AppLink recipient application rights database, as depicted in Figure 
18, it could be verified that the recipient owns or is renting the application or otherwise has rights 
to use the application. If the recipient did not have rights to use that application, the AppLink 
application selection algorithm could search for another application which had terms that allow 
that user to use the application. Such terms could include applications licensed by the 
application service provider on a "per seat" basis, that is, not assigning rights to individual users, 
but, for example, to a maximum number of simultaneous users, whose identity could change. 
The terms might include free "demo" licensing for AppLink recipients. Another type of 
application which might be considered by the algorithm could be an "Open Source" application 
which typically has a license permitting unrestricted use. 

The algorithm could also consider other applications for which the recipient has rights, 
and which are compatible with the file being AppLinked, but not necessarily the application used 
by the AppLink sender to create the file ("native application"). As a lower priority, a compatible 
"viewer" application with appropriate licensing could be selected, with the limitation that the 
user may not be able to interact with the file to the degree that he could if a fully capable native 
file application were used. This embodiment of the present invention, by which licensing 
impacts application functionality, may be implemented in conjunction with a previously- 
discussed embodiment, by which various application versions have different functionality in 
order to effect file permission security. That is, licensing terms may give differing levels of 
functionality for different payments to the vendor or different circumstances. A "demonstration" 
license might require disabled functionality. 

As an example, illustrative in that many possible file access avenues are explored, 
assume that a user "Joe" has created a flowchart with the Microsoft® Visio® for Windows® 
application. He creates an AppLink to the file and sends it to recipient "Larry". The selection 
algorithm would first see if Larry is on file with an Application License Tracking Database that 
the algorithm has access to. If Larry is found, the algorithm looks to see if he has rights to Visio, 
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the application used to create the file. In the event that he does not, the algorithm looks to see if 
the Visio software vendor is perhaps allowing AppLink to be used to non-owners as a marketing 
mechanism. If the Visio vendor is not, the algorithm then looks for other applications that Larry 
owns or has rights to which are capable of opening the file. In the event that he has none, the 
algorithm then looks at applications that the application service provider has licensed on a per- 
seat basis that are file-compatible. If the ASP has none, the algorithm then looks at open source 
programs that the ASP has available to it to see if any are file-compatible. If none are, the 
algorithm then looks to see if the ASP has any less-capable "viewer"-type applications with 
appropriate licenses that could be used to at least display the file to the recipient. In the event 
that the ASP does have such a viewer, the algorithm selects it and the AppLink Server presents 
the file to Larry inside the viewer. As a further implementation of this license tracking function, 
a database may be provided for use by an AppLink Recipient Application Selection Algorithm as 
described above, which contains the software applications and license terms that an AppLink 
recipient has rights to. An AppLink Recipient Application Selection Algorithm according to the 
present invention could function without knowledge of the application rights of AppLink 
Recipients, but access to such a database would improve the performance of such an algorithm 
by increasing the number and quality of the choices available to it, ensuring that the optimal 
legal application is used for file access. 

The Application Choices available to an AppLink Recipient may be enhanced according 
to an embodiment of the present invention: The AppLink Recipient Application Rights Database 
described above may be enhanced by way of a method to increase the number and quality of 
application choices available to an AppLink recipient as follows: When an AppLink recipient 
activates an AppLink, the AppLink Server determines the optimal application to open the file. 
Normally, the best choice for file compatibility and ability to interact with the file will be the 
native application, i.e., the application used in the creation of the file. However, if that 
application has restrictive, fully paid-up, perpetual "ownership" type licensing, that is, a recipient 
must legally own, rent, or be a licensee of, a copy of the application in order to use it, then there 
are several methods that could be used to allow the recipient to use that application to open the 
file. For example, it may be determined whether the recipient already has rights to use the 
application because he already has taken a license or is renting the application. This procedure 
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would involve asking the AppLink recipient for identification information, and querying a 
database of users and their application permissions to see if there is an entry for the recipient. 

If there is an entry for the recipient, it may be determined whether the recipient has rights 
to use the optimal AppLink application, which may typically be the native application. If so, the 
file may be opened in the optimal application. However, if there is no entry for the recipient, 
they may be notified that the optimal application to open the AppLink requires that he have 
rights to use it. The recipient is preferably informed as to which application is considered the 
optimal application. The recipient may then be prompted to enter application rights information 
into a database, which would typically include at least Recipient Identification information, and 
any suitable applications he has legal rights to use. Optionally it could include software 
ownership verification information such as product key codes, and, the duration of the product 
license or "rent" (a limited license term) period. If the recipient does enter this information, it 
may be confirmed whether the recipient in fact has rights to use the optimal AppLink 
application, by, for example, cross-checking a software vendor's database of registered 
application owners. If this information is confirmed, the file may be opened in the optimal 
application. 

If, on the other hand, the recipient does not have rights to the optimal application, 
according to a preferred embodiment of the present invention, they may be presented with an 
offer to attain such rights, including offering to license the application to the recipient through 
sale or rental, preferably immediately to facilitate his opening the AppLink. "AppLink" 
application rental licenses could be provided, according to the participation of software 
application licensors, on a "fee per use," based on a session or duration basis. 

In an additional embodiment of the subject invention, depicted in Figure 30b at 4004, an 
AppLink may be used to minutely track file access in great detail. Since an AppLink is a server- 
based application, the server can record various details of AppLink access for later review. This 
is an advantage AppLink has over e-mail, where typically the sender does not know whether the 
e-mail has ever been read. There are receipt provisions in some e-mail programs, but this still 
does not tell the sender whether the e-mail has been read, or an attachment opened. In 
conjunction with the file access tracking functionality described above, the AppLink Server may 
record details of AppLink use for later review or analysis by the AppLink sender or creator. This 
may include, but is not limited to, whether the document has been opened, how long it stayed 



59 



open, the time a viewer spent on each page, and in fact could record the recipient's entire 
session, including cursor or screen view or framing movement for later playback. 

In a related embodiment, due to the server-based nature of the AppLink function, the 
sender may also be notified of AppLink Accesses via a notification of AppLink use to the 
AppLink sender or creator by some communications means e.g., SMTP e-mail, wireless pager, 
or telephone call, as depicted in the flow diagram of Figure 32 42. Such notification could 
include any information item or combination of items about the access, including but not limited 
to who accessed it, when it was accessed, for how long, and which pages of the document were 
accessed. This could be useful, for example, to a salesman who has sent an AppLink of a 
presentation to a client, and is enroute to that client for a sales call. His approach will be 
different if he knows that the client viewed his presentation, or never got around to it. An 
automatic pager or cell phone notification that the client has viewed the presentation, plus 
specifics such as time spent viewing it, would be of interest. 

Central control of AppLink Settings will allow organizations, such as a company, to 
centrally control its intellectual property and other confidential information, e.g., identifiable 
electronic patient records in the health care setting. This is effected, for example, by preventing 
employees from sending proprietary or confidential files to unauthorized parties, such as 
competitors. This will typically require that employees' interaction with a company's files is 
restricted to server-based applications, where the ability to download the file to an employee's 
local computer is not permitted, so that the files remain on the server. If some sensitive files 
reside on employees local computers, additional restrictions will be required, such as the 
requirement that all employee's e-mail programs do not have the capability to attach files to 
e-mails, and/or that an AppLink E-mail Gateway as described herein is established. 

In the central administration of AppLinks in an organization, for example, preferably all 
or some variable settings to outgoing AppLinks which will be sent by a group can be controlled 
centrally by an AppLink group administrator or File Librarian. Central control of AppLink 
Settings may be set according to Role or Group membership: For example, a company's central 
AppLink administrator may set more restrictive permissions for employees that work with more 
confidential company files, or for a group of customers of the company. The central control may 
alternatively, or in addition, be implemented according to File Type. For example, a central 
AppLink administrator may set more restrictive permissions for more confidential documents or 



60 



files. The file AppLink settings could further be varied according to any file metadata criteria, 
such as author, when created, subject matter, etc. 

The sender of an AppLink may also optionally require the recipient to view an 
introductory web page before viewing an AppLink, as depicted in Figure 5, which could include 
a requirement or optional request to enter information or perform an action, such as to enter 
various details about the document or the sender as a form of authentication; a means for 
collecting sender-specified information, such as a web-based form or embedded or linked-to 
server-based spreadsheet or database templates; text entry boxes for entering a name, a telephone 
number, an email address, a password, or any other sender-required or requested information; an 
explanation or a link to an explanation of what an AppLink is and how to operate within the 
AppLink environment; an explanation or a link to an explanation of the technical requirements 
for receiving an AppLink, such as the requirements to run the AppLink client; a hyperlink or 
GUI button which, when executed, submits any form data to the server and activates the 
AppLink; a library of other useful elements. Two examples as shown in Figure 5b: A clickwrap 
Non-Disclosure Agreement (NDA) form which the recipient must agree to by executing an 
"Agree" GUI button or typing "Agree" and entering their name, or digitally signing the 
agreement. And a legal "terms/conditions of use" agreement required for the use of the server- 
based software or digitally signing the agreement. 

Typically, files involved in collaboration would not have an introductory web page, or 
might only have the password or authentication provision, to minimize access steps required for 
persons that will be working with a document frequently. 

The present invention also admits, in an alternate embodiment, of providing an 
Application Window in a Web Site's Web Page. This may be referred to herein according to the 
tradename "Embed-an-App™ " According to this embodiment, the AppLink is embedded into a 
web page, as a thin-client-enabled application window which displays a specific file in a file- 
compatible application, for example, as a frame within a web page. The thin-client-enabled 
application windows may be included in a persistent web page which is a part of a web site 
containing one or more pages, as a permanent element of that page. The source code, e.g., html 
or JavaScript, for the web page may contain window creation code which specifies the size of 
the window, plus embedded code or a link which essentially acts as an AppLink to a specific 
server-based application, and possibly, though not necessarily, to a specific file within the 
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application. In the event that the web page viewer's computer did not have the requisite thin 
client program installed, upon first opening the web page with an application window, the viewer 
would be asked if he/she wishes the required thin client to be downloaded and installed. 

This embodiment may be distinguished from the AppLink transmission system where the 
AppLink is transmitted to a recipient as a hyperlink or hyperlinked graphic on a web page on a 
web site which is viewed by the recipient. Applications have been known to be displayed in a 
web page, as in the Tarantella web-enabling system or Java-based thin-clients that depend on the 
web browser's Java Virtual Machine. However, this display has been primarily a way to access 
the application, by calling up a Java-enabled web page window with the application displayed 
therein, when an application is desired. This is comparable to the way a user might call up a 
word processing application on his local machine. Just as that user could have several programs 
which he has minimized onto the taskbar at the bottom of the local machine's GUI, so could the 
user have several web pages or windows with embedded applications minimized at the bottom of 
the GUI. 

According to an embodiment of the present invention, however, one or more thin-client- 
enabled application windows are included in a web page which is a part of a persistent web site 
containing one or more pages, as a permanent element of that page, or as generated on-the-fly 
automatically or as requested by viewers, by a web page generation script or programming 
language, such as Microsoft's Active Server Pages, or ASPs. This inclusion of thin-client- 
enabled application windows into a web page provides expanded uses: For example, a company 
web site could have a presentation program presented in a web page's window, with a 
presentation file loaded and ready to run when desired by a viewer. A financial advisor might 
have a spreadsheet presented in a window on his web site, with a template loaded which would 
allow a viewer to enter his personal financial information and run a macro which would calculate 
how much money the financial advisor may save the viewer. A software vendor could have web 
page windows on the corporate web site which show each of the vendor's software applications. 
In this case, there may be no specific file displayed, or there may be an example file loaded. 

In other words, this embodiment of the present invention, which may be termed the 
"Application Window in a Web Site's Page", or "Embed-an- Application", may be distinguished 
from the AppLink transmission system where the AppLink is transmitted to a recipient as a 
hyperlink or hyperlinked graphic on a web page on a web site which is viewed by the recipient. 
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In that case, the application window does not appear in the web page. In the instant embodiment, 
however, a window containing a server-based running application is embedded within a web 
page. The applications are actually running on a remote server, and when the viewer opens a 
web page with such a program "embedded", a Java-based or native client program downloads 
itself to the viewer's local machine and displays within one or more windows in the web page 
the interface to one or more applications, with perhaps a specific file opened and in view. A web 
page or browser window could contain many such windows, as depicted in Figure 49, below. 

A specific embodiment of the present invention that has been referred to above, is the use 
of an Application Window in a Web Site's Web Page, or "Embed-an-App" as used to implement 
a medical record confidentiality and control system. A patient's medical record may consist of 
several files in different locations. Some files would be viewed and manipulated by high-end, 
perhaps proprietary applications, such as an x-ray imaging and interpretation program. 
Documentation of a patient's laboratory work-up or clinician interview examination might be 
presented within a word processing program specialized for rapid medical dialog entry. The 
totality of the patient's files could be presented to a doctor with access to any Internet-connected 
computer within a single web page, with each file presented within a compatible server-based 
application. A central or unifying patient's medical record web page may be created that may 
contain a series of hyperlinks (AppLinks) that call up a file in an application, or windows that 
display the application and file. For example, when a clinician clicks on an AppLink icon for the 
patient's x-rays, the x-ray interpretation program would come up in its own window. This solves 
the problem of files located in different places and accessed by different applications. In this 
specific embodiment relating to medical record control, an AppLink may be created to Multiple 
Files Within a GUI Desktop as described in a previous embodiment. 

In a further embodiment of the instant invention, a Communications AppLink, which 
may also be referred to herein according to the tradename "CommLink™." In this embodiment, 
the server-based application is one or more communications programs, such as an e-mail, Instant 
Messaging, Chat (IRC), Voice Chat (Voice Over Internet Protocol), or Video Chat application or 
executable. The communications program may preferably be preconfigured with the 
communications address of the sender. The Communications AppLink can then be used by the 
AppLink recipient to communicate with the sender, who will have a compatible communications 
program, either server-based, or locally installed. This "CommLink" could be sent along with an 



63 



AppLink to another file that the sender wishes to collaborate with the recipient about, or have the 
recipient view and discuss. A depiction of a screen view of a suitable CommLink GUI 
implementing a Voice Over Internet Protocol application (voice messaging or chat) is depicted in 
Figure 19a at 1910. Figure 19a is a depiction of a user interface for a communication link 
according to an embodiment of the present invention. Using AppLink or Embed - an - App , access 
to one user's communication tools could be sent to another user via server-based 
communications programs in a web page or e-mail. Suitable applications may include Instant 
Messaging, as in Figure 19b, email, or voice over IP and video conferencing in those instances in 
which the local client program can access the relevant components of the local machine, such as 
the microphone or WebCam. Figure23 is a depiction of a screen view for an alternate 
implementation of a communication link according to an embodiment of the present invention. 
The recipient could communicate with the sender despite having no compatible communications 
programs installed on his local machine. This would allow guaranteed reliable communication 
with any number of recipients in a manner fully supported by both/all users, with no problems 
with incompatible or conflicting proprietary communications applications or executables. The 
communications applications could be configured, according to the desires of the sender, to 
allow the recipient to only communicate with the sender, for example according to the sender's 
addresses already set up in the application. 

An AppLink provides for file independence, since the application can be "sent" along 
with the file. Similarly, in the Communications AppLink embodiment, or the alternative 
Communications Embed-an-App embodiment of the present invention, the sender "sends" the 
communications program along with the web page or URL. Accordingly, in communications- 
oriented embodiments, the recipient need not have a communications program resident on their 
local machine. Additionally, the communications program linked to by the CommLink can be 
optimized for communication with the sender. It can be automatically or manually configured to 
contain the communications address of the sender, or of a specific group of collaborators. 

Another embodiment of the present invention provides for the combination of Program 
Sharing and AppLinking. A Program Sharing AppLink would allow the server-based application 
that presents an AppLinked file to the recipient to be "shared" real-time between two or more 
users, typically the sender and the AppLink recipient(s) for the purpose of collaboration. 
"Program Sharing," or "Session Shadowing", allows multiple users to interact with the same 
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document simultaneously, as depicted in Figures 20, 21, and 22. Figure 20 is a depiction of a 
process flow, with corresponding user interfaces, for a collaborative communication system 
according to an embodiment of the present invention. Figure 20 shows a suitable GUI for the 
administration of a collaborative communication session according to an embodiment of the 
present invention, together with a process flow for the creation of such a session. An AppLink 
recipient may activate an AppLink as discussed previously. To establish a communication 
session, the recipient may communicate with the sender, requesting a program sharing session. 
In response, the sender may query the AppLink server by executing, e.g., a "current AppLink 
activity" GUI button, which will display the sender's currently active AppLink sessions. 
Identification information regarding the sessions may also be supplied. 

The sender may indicate, e.g., via GUI radio button or check box, which sessions he 
wishes to be collaborative through the use of program sharing. The sender may then be 
presented with an interface to indicate which sessions he wishes to copy to the would-be 
collaborators. This may be the sender's session or another AppLink session currently running. 
The selected collaborators are presented with a thin client environment housing the selected 
session, which all collaborators can see at the same time on their remote device. The sender may 
select an additional session for collaboration as well. Collaborative users may have a single thin 
client running one collaborative session, or they may have multiple sessions, which may differ 
from the combinations of other session participants. 

Figure 21a is a depiction of a process flow for a collaborative communication system 
according to an embodiment of the present invention. Figure 21a depicts a network environment 
as it exists prior to the effecting of a program sharing session. Each user, or would-be 
collaborator, is presented with a separate session, which is not shared by any other user. The 
users maintain network links through a network such as a public network or internetwork to 
sessions running on the AppLink server array or application server, shown in the top tier of 
Figure 21a. The user's respective displays are shown in the bottom tier of Figure 21a. Figure 22 
is a depiction of a process flow for a collaborative communication system according to an 
embodiment of the present invention. Figure 21b depicts the network environment following 
creation of the session or sessions, creating a virtual network architecture as shown. The owner 
of the AppLink account or administrator of the session may enable the sessions, the data flow of 
which is shown by the solid line. The recipient collaborators continue to maintain their sessions 
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and corresponding session thin-client GUIs. Each user can move the application's cursor and 
otherwise interact with the program. Coordination between multiple users about who is currently 
interacting with the program can be done informally, or in some variants, control of the 
application must be formally requested and granted by the current controller. According to the 
present invention, AppLink functionality is combined with a program sharing capability. Since 
the program is running on the server, it is possible to split, or "copy" the data flow from the 
application server to the first interface thin client to one or more additional thin clients, running 
on different remote machines. The AppLink can serve as an initial connection mechanism to the 
AppLink Server, and thus to the AppLink sender, who can view which AppLinks are being used 
at any point in time. The actual program session that is shared can be the AppLinked file 
program session, or any other session extant among the online AppLink sender and recipients. 
The session can be changed at any time. 

There are two ways to implement a combination AppLinking and Program Sharing event 
with regard to the recipient's existing sessions, that is the sessions that were in existence prior to 
program sharing. One is to take over the application windows of the persons being shared with 
and replace that windows contents with the session to be shared. The recipient's sessions would 
continue to run, but not be visible to the recipients until the session sharing is terminated. A 
second, preferred mode, is to generate a second application window on each recipient's computer 
GUI desktop with the shared session. That way, each recipient can continue running and 
interacting with their own session, and perhaps sharing that session with others later. 

The present invention provides application and file access to a much broader range of 
users than a normal Application Service Provider (ASP) model, where each user must be signed 
up with a particular ASP. 

Figure 23 and Figure 24 are is a depiction of user interface for an alternate 
implementation of a communication link according to an embodiment of the present invention. 
CommLinks could be included in a web page that also has an embedded application with a file 
that the sender wishes to collaborate with a recipient on as depicted in Figure 23. Through 
session shadowing or program sharing of that program window, both users can be viewing and 
working with the file simultaneously as shown in Figure 21 and 22. They can also be 
communicating with each other via the embedded or AppLinked communications programs. 
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Several of the embodiments of the present invention described above may be combined 
into what may be termed a multiple application or multiple file AppLink, which may be 
implemented by the integration of a CommLink embodiment with a Program Sharing 
embodiment. A depiction of a suitable GUI for transmission of a MultiFile AppLink is also 
shown in Figure 1 la and 1 lb. Figure 24a is a depiction of user interface for an alternate 
implementation of a communication link according to an embodiment of the present invention. 
Figure 24b is a depiction of an alternate implementation of a user interface for a communication 
link according to an embodiment of the present invention. Alternatively, the MultiFile AppLinks 
and attendant CommLinks may be combined into a single communication, e.g., a SMTP e-mail 
message as depicted in Figures 24a and 24 b, or an AppLink r e cipi e nt' s introductory web pag e 
depicted in Figur e 25 at 2510. Figur e 25 is a depiction of a us e r int e rface for a collaborativ e 
communication link according to an e mbodiment of th e pr e sent invention . 

According to this embodiment of the present invention, an AppLink can be created which 
combines one or more server-based communications programs plus a file or files in one or more 
application windows, frames, or displays, which can be program-shared. The communications 
program can be used to communicate with an AppLink sender, for example via a text or audio 
chat, or via an instant messaging application. The sender and one or more recipients can 
collaborate over a document via the Program Sharing capability. 

Figure 26 is a depiction of a user interface for an alternate embodiment of the present 
invention. In a further refined embodiment of the present invention, application interface 
settings may be altered according to file metadata. According to this embodiment, a user can 
associate a custom program interface setting with a file, for example, in the form of metadata for 
that file. File metadata is information about the file that may be contained in the file, for 
example as a file header, or external to it, for example, in a file database. For example, Figure 26 
depicts a typical GUI interface to examine the file metadata of a particular type of file. An 
application interface setting will preferably specify which menu items or tools would be present 
in the application as experienced by the user. The file metadata application interface settings 
could communicate with the application's APIs (Application Programming Interfaces, or 
protocols to communicate with and control a program) to customize the interface prior to 
opening a file. If that file is opened, the program would display the application interface 
specified for that file. Another user accessing the file through an AppLink, for example, would 



67 



be limited to the application settings created by the file owner or administrator, such as the 
author. Interface specifications file metadata could additionally have an additional association 
with a person or group, so that when that person or group opens the file, the user may be 
presented with a particular interface for the target application optimized for that person or group, 
for example, according to their work roles. For example, tasks that are never performed by 
members of a certain group may be eliminated, thus reducing clutter and simplifying the 
interface for that group. In certain situations, AppLink recipients may actually pay for and/or 
subscribe to certain functions or subsets of functions, eliminating those that they would not use 
from the interface and simplifying their experience of the application. 

The ability to "send" an application via AppLink for opening and working with a file 
means that the application can now serve different roles than originally envisioned by creators of 
the program. For example, in an embodiment of the present invention in which application 
Interface Settings are altered according to file metadata, a presentation file AppLink may be sent, 
with the sole purpose of having the recipient view the presentation. There is no necessity for the 
recipient to modify the presentation, indeed, the presence in the AppLink presentation 
application of tools necessary to create and modify the presentation could confuse the recipient 
who might be unfamiliar with the full functionality of the application. Accordingly, it would 
therefore be beneficial if the AppLink creator could modify the program that the recipient sees to 
eliminate confusing and unnecessary menu items and tools. The ability of the AppLink creator 
to customize the program interface to achieve particular goals also increases the usefulness of 
the ability to place an application window in a web site's web page. 

Figure 27 is a process flow diagram for an e-mail server according to a further 
embodiment of the present invention. In a further embodiment of the present invention and as 
depicted in Figure 27, an AppLink E-mail Gateway may be provided, by which a server, referred 
to as an AppLink E-mail Gateway Server 2701, screens all incoming e-mails for attachments. If 
an e-mail 2701 has an attached file 2702, this file is removed from the e-mail and stored on the 
server 2704 after being scanned for viruses. An AppLink to the file is created 2705 and the 
AppLink is appended to the e-mail 2706. The e-mail is then forwarded to its intended recipient 
2707, who opens the attachment via the AppLink 2708, thus eliminating the danger of computer 
viruses for the recipient's computer. In a related embodiment, but for a contrasting purpose, 
outgoing e-mail can be treated similarly, by removing and storing the attachments, and creating 
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an AppLink which is added to the e-mail instead. For outgoing e-mails, the replacement of all 
attachments with AppLinks may aid in the control of a company's intellectual property, by 
ensuring that the attached files remain with the company, and AppLink recipient file permissions 
or properties may be restricted centrally according to company policy and the recipient 
permissions in general. 

According to the present invention, an AppLink may be implemented as a viral marketing 
mechanism for service providers as follows: A link or other mechanism may be included in 
some or all sent AppLinks, depending for example on the subscription level of the sender or 
creator, whereby an AppLink recipient is advised or solicited regarding signing up with the 
service provider that is providing the AppLink capability to enable the recipient to send their 
own AppLinks. In this manner, incentive is provided to the recipient to sign up or register. 
According to this embodiment of the present invention, the novel capability of AppLink to 
deliver server-based applications and files to a broad range of anonymous or random recipients 
allows AppLink to be used as a viral marketing mechanism. Viral marketing typically may be 
thought to require two components: (1) a user motivated to use a service to communicate with 
others that are not currently members of the service, and (2) provision for nonmembers that are 
communicated with to sign up for the service. 

Since an AppLink is essentially a new and useful way to communicate with any number 
of recipients, it intrinsically provides the first component. The second condition can be satisfied 
as depicted in Figures 5 and 5b by including a registration form or a link included in a recipient's 
introductory web page for sent AppLinks which, if activated by the AppLink recipient, brings an 
AppLink recipient to some sort of informational web page which would include that ability to 
register with the service, perhaps through a limited time offer. 

Another means to facilitate viral marketing is to combine the thin client (required by 
AppLink recipients to activate and interact with an AppLinked file) with the means to create 
AppLinks. Each first-time AppLink recipient will have to download some sort of thin client. If 
that download also includes means to create an AppLink, perhaps as a plug-in to an email 
application, the "viral marketing" propagation of users of the AppLink service provider should 
be considerably enhanced. The e-mail plug-in could be preconfigured to use, for example, a free 
trial account offered by the AppLink service provider for a limited time. 
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Another means of facilitating viral marketing for the AppLink service provider is to use 
the occasion of a recipient trying to activate an inactive AppLink as a marketing opportunity. 
The recipient could get a web page containing an error message, as depicted in Figure 36 . but 
one that also includes an offer to let the recipient try out AppLinking, perhaps with AppLinks to 
several "demonstration" files, such as a spreadsheet, word document, and presentation file. 

Another embodiment where the use of AppLinks can act as a viral marketing mechanism 
for Software Vendors or publishers is by way of an AppLink Recipient Demo Application 
License. According to this embodiment, a free "demo" license for AppLink recipients allows 
software vendors to present their application to potential customers via the viral marketing 
mechanism of AppLink. In a further refinement of this embodiment, a server-delivered 
application may be provided to AppLink recipients (who have not yet paid for application access 
rights) which contain various limitations on functionality, e.g., "demo-ware", where an 
application has a free demo period, after which a key code must be entered for further use; 
"annoy-ware", where some irritating feature, such as a fixed delay after opening the program 
until it can be used, is present until a key code is entered; "cripple-ware", where critical features 
such as a "print" function is disabled until a key code is entered; or "limited time-ware" where 
entry of a key code enables application usage for a specified time period. Information about 
increased functionality is preferably provided that may be enabled via entry of a key code which 
may, for example, be purchased from the software vendor or the application service provider. 

In addition to its use in AppLinks, thi s sam e key code syst e m for r e moving on - lin e 
application limitations may be used in anoth e r e mbodim e nt, d e pict e d in Figur e 28, by 
Application Service Providers in general, as follows: According to pres e nt m e thods of k e y cod e 
softwar e e nabling, th e k e y code is "purchas e d" from th e softwar e publish e r, e ither through on - 
lin e communication with the software publish e r, s uch as for downloadabl e applications, or 
print e d on th e softwar e packaging for physical media softwar e . According to th e pr e s e nt 
inv e ntion howev e r, such applications ar e mad e availabl e on lin e by an application s e rvic e 
provid e r, through serv e r bas e d application d e liv e ry. The s e rvic e provid e r could coll e ct a hosting 
f ee from th e us e r. This decouples tho paym e nt for th e program, which is coll e ct e d by th e 
s oftwar e v e ndor, and the payment for hosting th e program, if any, which is coll e ct e d by the 
application s e rvice provider. According to th e pr e sent invention, th e ASP do es not hav e to 
lic e ns e and manage the software rights. Those rights ar e purchas e d dir e ctly from th e software 
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vendor by the user. It allows us e rs to lic e nse or purchase program s onlin e , rath e r than r e nt th e m 
from an ASP. This e mbodiment pref e rably allows users to acc e ss programs online that th e y hav e 
already licensed for th e ir local machin e . This helps solves th e problem of a larg e bas e of 
already - paid - up licensed and install e d softwar e , by preserving that investment and r e ducing 
resi s tanc e to a migration to an online application d e livery mod e l. A suitabl e proc e ss for this 
embodim e nt of th e pr e s e nt inv e ntion is d e picted in Figure 28. Figure 28 is a proc e ss flow 
showing corresponding user int e rfac e s for a software registration sy s t e ms according to an 
e mbodim e nt of th e present inv e ntion. An onlin e ses s ion may b e originat e d, after which a us e r 
may s e l e ct program s for an initial investigation, demonstration, or us e . Alt e rnatively, a us e r may 
select programs alr e ady e xisting in the user' s account, i. e ., th e us e r has already paid 
con s ideration for a lic e ns e or for a purchas e d copy of the software b e ing consid e red. Th e 
software may op e rate in one of s e v e ral limit e d modes. The user may have a key cod e from a 
pr e vious purchase or still - valid licens e for th e software product, which th e y may e nt e r. 
Alt e rnativ e ly, th e us e r may "purchas e " an appropriat e k e y cod e from the vendor or pay a f ee for 
a lic e ns e to th e softwar e , for which th e us e r is given an enabling k e y cod e . In e ith e r e v e nt, th e 
us e r may e nt e r th e k e y cod e at a us e r int e rfac e . Th e us e r may also b e prompt e d to e nt e r a 
password in a textbox for auth e ntication. Whil e th e softwar e program had be e n operating in a 
limit e d mod e , upon entry of th e k e y cod e th e program may comm e nc e to operate in unlimit e d 
mod e . In this way, th e ASP is not involv e d with program activation, and may charg e a program 
hosting f e e as well. Th e program lic e ns e rev e nue goes directly to th e softwar e v e ndor. Softwar e 
may b e mad e availabl e for us e in thi s way without lic e ns e agr ee m e nts, becaus e th e ir rights ar e 
prot e ct e d by the limitation occurring to th e software if th e k e y code is not provid e d. U se rs g e t 
th e b e n e fit of k e y cod e s they alr e ady own. K e y cod e s may be match e d against authoriz e d us e rs, 
and authentication may be used to prev e nt k e y cod e sharing. Figur e 29 depicts this proc e ss in 
conjunction with a databas e syst e m of k e y cod e validation. Following creation of an AppLink, a 
list of suitable applications may be ranked from most to least suitable for the AppLink file. 
Upon execution, as depicted in Figure 1 at 624 and in Figure 18, the AppLink server may go 
down the list, and as soon as the user has the right to use an application choice, the application 
server is prompted to start this application. If the user does not have the best choice, their license 
or purchase of this choice may be solicited. A database may be accessed to determine the current 
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application rights of the user. If no application can be validate or otherwise provided to the user, 
they may be provided with an error message. 

Und e r pr e s e nt systems of k e y - codo software e nabling, with softwar e install e d on 
consumer PC s for e xampl e , k e y cod e sharing in violation of th e us e r's lic e ns e is common. Figur e 
29 is a process flow diagram for a software right s control sy s t e m according to an e mbodim e nt of 
th e pr e s e nt inv e ntion. According to an e mbodim e nt of th e pr e s e nt invention, th e On - lin e 
Application Purchas e Model of an embodiment above may b e combined with a k e y cod e 
database as depicted in Figure 29, by which the ASP ha s acc e ss to a database of issued k e y 
cod es , p e rhaps maintain e d by the softwar e v e ndor, with the database optionally including oth e r 
custom e r - v e rification information such as custom e r nam e . This would allow th e ASP to verify 
that th e k e y cod e off e r e d by th e custom e r is not only valid, but unique, that is, not being us e d by 
anoth e r us e r. 

Where a user has multiple AppLinks to multiple files or applications or computer 
"desktops" on one or more servers located in the same or different data centers operated by the 
same or different service providers, this constitutes an "AppLink Library". A user could create 
multiple AppLinks to his files from different servers operated by different service providers. By 
keeping a list of AppLinks to each file, or to a desktop work area for each server, the user has a 
central library of his files and applications. Such a list could be kept in a web browser's or web 
home page's URL "bookmark" list. This aggregation of AppLinks could serve as a user's 
document library, and could be stored locally or on a central database. On e disadvantag e of this 
arrang e m e nt i s that curr e ntly fil es on one s yst e m cannot b e op e n e d with applications on anoth e r 
s e rvic e provider's system. 

Currently, multipl e and som e times incompatibl e fil e systems are b e ing us e d by diff e rent 
comput e rs, s e rv e rs, or data storag e d e vic e s. Combining such diff e r e nt fil e syst e ms in a us e ful 
way is difficult and complicat e d. What is mis s ing i s a way to quickly and s e aml e ssly combin e 
thos e syst e ms into one integrat e d and unified syst e m. A metafil e syst e m links togeth e r all 
n e twork - conn e cted computing d e vice s and cr e at e s a single, seaml e ss r e sourc e . A furth e r 
embodiment of th e pr e s e nt inv e ntion provid e s for a "M e tafile System," i. e ., a network - conn e ct e d 
comput e r serv e r or s e rv e r clust e r, which may be referr e d to by th e trad e nam e M e taserver™, 
togeth e r with on e or more network conn e ct e d computers, servers, or data c e nters wh e r e on e or 
mor e us e r's files arc s tored. This e mbodiment is d e pict e d in Figur e s 30 through 33. Figur e 30 i s 
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a data flow diagram showing metafil e s e rver oporation according to on e mbodim e nt of th e 
present invention. Figur e 30 depicts a metafile server databas e according to an e mbodim e nt of 
the pres e nt invention. A us e r via th e ir r e mot e machin e may acc es s a m e tafil e s e rv e r databas e 
over a n e twork, e.g., a public network or int e rn e twork. Through th e us e of Dir e ctory Access 
Protocols, e.g., ActiveX, Bindery, DHCP/BOOTP, DNS, HTTP, IETF dial in, Java, LDAP, 
NCP, NDAP, NT Domains, ODBC, PKI, PKCS10, RADIUS, SMB, SSL, X.50Q, XML, 
WcbDAV, or oth e r protocols, the metafile s e rv e r file databas e may access remot e s torag e 
devices, indicated g e n e rally, via a n e twork, which may b e a public n e twork or intern e twork. Th e 
Metafil e S e rv e r Fil e Databas e is able to access any of various Dir e ctory types or servic e s, 
including but not limited to Nov e ll Dir e ctory Services and its att e ndant storage, an NDS Disc 
Array; Windows Dir e ctory Servic es and an att e ndant Window s 2000 s e rver, or a PC file acc e ss 
cli e nt proc e s s and the PC's hard driv e . Figur e 3 la is a proc e s s flow diagram showing metafil e 
s e rv e r op e ration according to an e mbodim e nt of th e pr e s e nt invention. Figure 3 la d e picts th e 
process for the r e qu e st of a m e tafil e fil e request. The us e r initially logs in from a client machin e . 
Th e us e r is presented with a list of th e ir fil e s, and th e us e r may requ e st to op e n a fil e . Th e 
metafil e s e rv e r looks up th e fil e nam e , re s olving any alias naming that has be e n impl e m e nt e d, 
and determines from th e databas e th e location of th e fil e in th e storag e devices, the appropriat e 
dir e ctory acc e ss protocol from those indicated in Figur e 30, for e xampl e , and the fil e 
transmi s sion protocol. Th e m e tafil e s e rv e r r e qu e st s th e appropriat e access protocol subroutin e to 
r e tri e v e th e fil e , and op e ns th e r e qu e st e d fil e in th e onlin e application, which may b e pr e s e nt e d to 
th e us e r via a thin cli e nt e nvironm e nt a s discu sse d h e r e in. Figur e 3 lb is a syst e m archit e ctur e 
diagram of a metafil e s e rv e r sy s t e m according to an e mbodiment of th e present invention. 
Figur e 3 lb d e picts the broad softwar e archit e ctur e of the metafile main program. Th e us e r 
acc e ss e s th e monolithic metafil e main program, the components of which ar e pr e f e rably 
transparent to the u se r. Th e Metafile Main program components include c e ntral control 
algorithms, intelligent file manag e ment algorithm s , and dir e ctory acc e ss protocols and fil e 
transmis s ion protocols as discus se d with r e f e rence to Figur e 31a abov e . An int e rfac e to th e 
storag e devic e s is provided to th e M e tafil e Main program. Figure 32 is a depiction of a m e tafile 
s e rver e ntry according to an e mbodiment of th e present invention. An exampl e populated field 
for a r e cord of the m e tafile s e rver showing us e r fil e lists e ntri es is d e picted in Figur e 32. As 
shown, a us e r's file list may indicate the following fields: th e user's alias or "us e r fri e ndly" file 
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name, th e corresponding actual file nam e , tho location of this file among the available storage 
devices, the fil e dir e ctory sy s t e m us e d, th e fil e transmission protocol and/or n e twork type, and 
file use information including th e author, the dat e and tim e of last acc e ss, any us e r groups or 
genera to which th e us e r b e longs, and th e URLs giving th e location of corr e sponding AppLinks. 
Figure 32 also d e picts a populat e d fil e list record for a us e r s howing th e location of a file in the 
storag e d e vice of a us e r PC. Figur e 33 is a proc e s s flow diagram of alt e rnativ e m e tafil e s e rv e r 
process e s according to an e mbodim e nt of th e pr e s e nt inv e ntion. Figur e 33 d e picts th e 
optimization strat e gies availabl e to the m e tafil e s e rv e r according to a repr e s e ntative e mbodim e nt 
of th e pr e s e nt inv e ntion. An individualized file location may b e d e t e rmined according to 
frequency of us e , for e xampl e . Th e fil e admini s trator may s e t a "fil e unus e d tim e " for fil e 
mov e m e nt or fil e cascading to low e r cost and slow e r s torag e . Bas e d on p e riodic polling, 
inventory, s w ee ping, or th e lik e , if it is d e t e rmin e d that the "fil e unused time" exceeds th e s e t 
param e t e rs, th e file may b e mov e d to low e r cost storag e as indicat e d. A s d e pict e d below, when a 
user creates an AppLink to a fil e on a laptop or oth e r d e vic e prone to removal from th e n e twork, 
a copy of th e file may be mov e d to p e rsi s t e nt, "always on - lin e " data storag e . If it is d e t e rmin e d 
that an AppLink is cr e ated to a file but the fil e is not locat e d on p e rsist e nt storage, a copy of the 
fil e may b e plac e d in p e rsist e nt s torag e , with AppLink param e t e r s updated accordingly. 

Fil e s may be provid e d with redundancy based on their importanc e . According to this 
embodim e nt, files may be assign e d a c e ntrally set variabl e r e dundancy based on individual fil e 
charact e ristics. An important fil e could b e giv e n, for example, a redundancy level of "5," 
meaning for exampl e that 5 compl e t e copies of th e file or file set are availabl e in diff e r e nt 
storag e device location s . Finally, if a fil e is id e ntified as having n ee d for high s e curity, th e 
m e tafil e s e rv e r may mov e such fil e to a storage d e vic e having th e r e quisite security param e ters, 
according to the file s e curity l e v e l rating or numb e r assign e d to the file or fil e typ e by a fil e or 
n e twork administrator. 

These may be t e rm e d gen e rally Storag e Devic e s, or SDs. This M e tafil e Manag e ment 
Syst e m would pr e f e rably be impl e m e nt e d with th e following components: Th e SDs would 
pr e ferably have a protocol or m e ans for th e M e tas e rver to interact with the SB to accomplish file 
manipulation functions, such as mov e , upload, download, alter, delete, or copy. Thi s could be 
via protocols alr e ady built into th e SB's fil e system, , via accessing th e particular dir e ctory 
s e rvic e b e ing used by the SB, or through a custom program install e d on th e SB, such a s a web 
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scrvor/W e bDAV combination, which would allow th e M e tas e rver to perform the requir e d 
functions. 

- The Metas e rver may b e configur e d so as to contain a c e ntral databas e of on e or mor e 
user's file s and file m e tadata. Th e m e tadata would pr e ferably include, at a minimum, th e 
location of the file, data about th e fil e system used by th e computer or s e rver storing th e fil e , and 
any nec e ssary acc e ss information such as passwords or a pointer or reference to such 
information. The databas e e ntry for each file could also includ e any other standard or us e r 
specifi e d file - specific metadata such as file access permissions, author/own e r, la s t modified dat e , 
etc. The M e tas e rv e r will pr e f e rably b e configur e d so a s to contain a protocol for e ach typ e of 
file syst e m and directory servic e that the Metaserv e r is int e nd e d to int e ract with, so as to 
accomplish file manipulation function s on the SB. Th e s e may includ e , for example, functions 
such as mov e , upload, download, alter, del e t e , or copy. Th e M e tafil e Syst e m provided by th e 
instant inv e ntion can link togeth e r multiple files, fil e locations, and fil e syst e m s , pr e s e nting th e m 
to th e us e r as a singl e fil e grouping. The Metas e rv e r manag e s th e different protocol s necessary 
to perform file action s b e tw ee n diff e r e nt file syst e ms. 

With a M e tafile s ystem according to th e pr e sent invention, th e ability to run applications 
on multipl e s e rvers or servic e provid e rs is link e d with a complim e ntary capability to manag e 
fil e s locat e d on multipl e s e rvic e providers s torag e d e vic e s, thus providing a way to transfer fil e s 
from on e s e rvic e provid e r's syst e m to anoth e r. This functionality is in addition to th e alt e rnativ e 
m e thod, that is to download a fil e onto th e user's local machin e and then upload it onto a 
diff e r e nt s e rv e r. 

Th e multipl e locations and fil e s yst e ms which a m e tafile system mak e s possibl e may b e 
consid e r e d an advantag e of th e distribut e d natur e of fil e storage according to the present 
invention. These characteristics mean that th e m e tafile system is r e quired for the us e r to acc e ss 
the fil e s. The user may not even b e aware of th e actual physical location of th e s torage d e vice 
containing hi s file, or of the operating sy s t e m of th e Storage Devic e b e ing acc e ssed. This also 
means that an administrator can s e t diff e rent p e rmissions for each us e r of th e M e tafil e Syst e m, 
aiding in Int e llectual Property and confid e ntial information control, e nhancing th e c e ntral control 
by an admini s trator of user permissions of a m e tafil e syst e m. 

This Metafil e System with C e ntral Control may b e further e nhanc e d, according to an 
embodim e nt of th e invention, through th e us e of Intelligent File Manag e m e nt, i. e ., th e ability of a 
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Metafil e Sy s t e m to int e grat e multiple SDs of varying p e rformanc e , se curity, and cost pr e s e nts 
new problems of optimization oth e r than s imply tracking fil e location. Th e s e variabl e 
characteri s tics of SDs ar e tak e n into account by int e lligent file management rul e s that ar e 
designed to optimiz e th e s e r e sourc e s as follow s : C e ntral control i s provid e d to an administrator 
via automatic fil e management rul e s for a Metafile Syst e m. According to this e mbodim e nt, 
optimal fil e location may b e s e t according to various Storag e Device (SD) criteria such as 
storag e co s t or s e curity; and/or according to file m e tadata such a s usag e /acc es s fr e qu e ncy, 
importance, r e quired security, fil e cr e ator/owner, or s e tting th e number of backup copi es of a fil e 
according to it' s importance and the availability and cost of backup storag e s pac e . In a sp e cific 
e mbodim e nt of this Int e llig e nt Fil e Manag e ment, the ability to associate any type of metadata 
with a particular fil e is provid e d, allowing an administrator to sp e cify rules for intelligent fil e 
manag e m e nt which would b e carri e d out by th e Metas e rv e r. 

As an example of the embodiment of Intellig e nt Fil e Management Rul e s in practic e , 
suitabl e rul e s might b e a s follows: (1) Fil es which hav e not b ee n used for a sp e cifi e d tim e p e riod 
might b e mov e d automatically off of high - cost, always - network - availabl e storag e such as a 
dedicated data center's disc array and onto a low e r - cost n e twork - conn e ct e d PC' s hard driv e . (2) 
Wh e n a us e r cr e at e s an AppLink to a fil e on his laptop, a copy of that file is moved to high - cost, 
alway s- n e twork - availabl e storag e , b e caus e if th e laptop is r e moved from the network and a 
r e cipi e nt att e mpts to e x e cut e th e AppLink, th e fil e will not b e availabl e . (3) A particularly 
important file, such as a custom e r databas e , could b e support e d by backup r e dundancy bas e d on 
it s high importance. For e xampl e , this fil e could hav e as many as 5 or mor e diff e r e nt copi e s in 
diff e rent locations. (1) Files that n ee d to b e kept s ecure would b e k e pt on s e cur e storag e , s uch as 
a disc array at a secur e facility, r e gardl e ss of fr e qu e ncy of use. In thi s mann e r, c e rtain Int e llig e nt 
File Manag e m e nt Rul e s according to th e pr e s e nt invention may hav e imp e rativ e or absolut e 
status, thus trumping oth e r subs e rvi e nt rule s . 

In a further refinement of Int e lligent File Management, Graded and/or Monitored Storage 
may b e provid e d. For e xample, a Metaserv e r which implements a system of Intelligent File 
Manag e m e nt Rules could us e fully e mploy information about the Storag e D e vic e s availabl e to it. 
This information could include the s peed of access, including the speed of th e network 
conn e ction, i.e., the bandwidth available between th e SD and the Metas e rv e r. It could further 
includ e th e persistenc e of th e conn e ction, if the SD is occasionally remov e d from the network, as 
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with a laptop computor or fr e qu e ntly - maintain e d s e rver or one that is e mpirically frequently not 
operational 

This information about the SD could simply b e e nt e r e d by an administrator, or could 
actually b e monitor e d and tracked by th e Mctaserv e r automatically. For e xample, a laptop would 
bo observ e d by th e M e taserv e r to b e only intermittently connected to th e n e twork, while a 
de s ktop PC would b e obs e rv e d to be almost always conn e cted to th e network. Th e Mctaserver 
could th e n manag e file location automatically in light of this SD p e rformanc e and access 
knowl e dg e . For e xampl e , th e M e taserver might move seldom - us e d fil e s that still hav e an 
outstanding AppLink onto th e d e sktop PC. It might mov e n e ver - used files onto th e laptop. 

This c e ntral control bas e d on M e tas e rv e r manag e ment may b e combin e d with Doubl e 
Entry File Naming. According to this embodim e nt, a metafil e syst e m wh e re th e actual fil e 
name s us e d by th e SDs for th e files arc s hi e ld e d from us e rs by linking an Actual Fil e Nam e to a 
diff e r e nt fil e nam e that th e us e r can vi e w and chang e (Us e r Fil e Nam e ). Typically, th e actual fil e 
nam e would b e a d e signation without m e aning, such as a p se udorandom or arbitrarily determined 
s e t of numb e r s and l e tt e rs. Th e Metaserv e r' s databas e e ntry for a file would contain both th e 
Actual File Name and th e Us e r Fil e Name. When a us e r r e qu e sts acc e ss to a fil e via th e Us e r 
Fil e Nam e , th e M e tas e rv e r will look up th e Actual Fil e Nam e and location, and us e this 
information to acc e ss the file. Typically, in this cas e , the actual physical location of the file in 
t e rms of its SD placem e nt would also b e hidd e n from the user. 

On e or more AppLinlc s may b e e mb e dd e d into an HTML - bas e d or Rich Text Format 
(i.e., Microsoft' s HTML format), or XML ( e xt e nsible Markup Languag e ), or any other 
compatibly formatted docum e nt, as thin - cli e nt - enabl e d applications in a window, which may 
display a specific file in an application compatibl e with that file. The source cod e for the 
application window would contain window - cr e ation code which sp e cifics th e size of th e 
window, plus cod e or a link which acts in a manner comparabl e to an AppLink to a s p e cific 
server bas e d application. This may optionally contain a link to a specific fil e nativ e to th e 
application. The Document format requir e s information regarding the position and siz e a 
window in the docum e nt, and will call up an outside process, such as th e thin client. Opening 
the document calls up th e thin cli e nt and commands th e server to open th e requested application. 
The thin cli e nt then displays the application inside th e designated window. 
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Th e e mbodiment of th e present inv e ntion by which an application window may be 
embedded into a web pag e ("Emb e d an - App"), may be e xtend e d to provide for the insertion of 
such a window into an appropriat e ly formatt e d e mail, e .g., an SMTP transmis s ion utilizing 
HTML, RTF, or XML formats. If th e vi e wer's comput e r did not hav e th e r e quisite thin - client 
program install e d, upon first opening the e - mail with an application window, th e vi e w e r would 
be asked if h e /sh e wi s h e s th e r e quir e d thin - cli e nt to be download e d and install e d. 

In oth e r words, the sam e basic principl e s of emb e dding an application window into a 
docum e nt with the proper format can b e used to insert such a window into an appropriat e ly 
formatted e - mail, such as th e HTML or Microsoft's RTF or XML format s . Accordingly, 
according to th e pr e sent invention, an application window for thin - cli e nt e nabl e d applications 
may b e insert e d into compatibl e e- mail formats. A format is compatible to the e xt e nt that it 
allows a way to position and siz e a window in the docum e nt, and call up an outside process. 
Compatibl e format s would thus includ e , for e xampl e , HTML, Rich T e xt Format (RTF), and 
XML ( e xt e nsibl e Markup Languag e ). 

Generally, AppLink creation can be optimally joined with or linked to the means of 
transmission to intended recipients, to minimize the number of steps the AppLink creator is 
required to perform, or to minimize the number of applications the creator is required to use. 
Often, this transmission method will be e-mail. Therefore, incorporating AppLink generation 
into an e-mail program to automate some of these steps would have efficiency and convenience 
benefits for the end user in the creation and transmission of AppLinks via e-mail. 

According to an alternate embodiment of the present invention, an AppLink is created 
and executed via communication with the AppLink Server by the native code of an e-mail 
application, or an addition to the e-mail program, such as through a plug-in or add-on program. 
This add-on could interact with the e-mail program through program APIs, thus the creation code 
could facilitate any of the possible transmission formats. Generating an AppLink through an e- 
mail interface would include the following steps: 1) Selection of the file to be AppLinked; 2) 
Setting of AppLink properties (or the acceptance of previously set parameters); 3) Generation of 
the AppLink address or URL; 4) Inclusion of the AppLink address in an e-mail, either as a naked 
link or linked to an inserted image. If including an Application Window in the e-mail according 
to the e-mail implementation of the embed-an-app embodiment described above, the sender 
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would be prompted to size and place the window in the e-mail. Finally, recipients could be 
selected and the e-mail sent. 

The inclusion of the AppLink address in the e-mail may be effected in one of several 
ways. One AppLink presentation method may be used if the AppLink transmission e-mail is in 
plain text format. In this case, the AppLink is inserted by the E-mail AppLink Insertion 
procedure as a naked link, for example as depicted in Figures 1 lb and 24b. such as: 

4rttfi ://FrcoDc s lc.com/AppLinlc s /3 1 5.65867 r^4#T 

An alternate AppLink presentation method may be used if the AppLink transmission e- 
mail is in a richer format such as HTML, RTF, or XML. In this case, as depicted i n Figure 1 la. 
the e-mail AppLink Insertion procedure can generate and insert an image into the e-mail 
representing the AppLink, with the actual naked AppLink address linked to the image via 
underlying code. The image could incorporate features to aid in communication with the 
recipient, such as a preview of the AppLinked document, or a thumbnail image of the document 
bearing a label with the name of the AppLinked file. Suitable source code implementing this 
embodiment, for an HTML-format e-mail would be: 

<A m^F="WWW.FREEDESK.COM/APPLINKS/345.67^ 
SRC- 'APPLINK BUTTON TO BUSINESS PLAN . JPG"></A> 

According to anoth e r e mbodim e nt of the pr e sent invention, an AppLink "Shortcut" for a 
user's local PC GUI "Desktop" may bo provided. One pos s ible implementation for thi s 
embodiment is d e pict e d in Figure 34a and 3 4 b. Figure 3 4 a is a proc e ss flow diagram d e picting 
th e cr e ation of a shortcut to an application link according to an embodiment of the pres e nt 
invention. Figur e 3 4 b is a proc e ss flow diagram d e picting the activation of a shortcut to an 
application link according to an embodiment of the present invention. Most potential us e rs of 
s e rv e r - ba s ed applications will also us e application s running on th e ir local PC. The Op e rating 
Syst e m GUI "desktop", such as the Microsoft Windows or Linux Gnome desktops, ar e w e ll 
known to s uch users. What is n ee d e d is a way to s e amlessly int e grate s e rv e r - based applications 
into that desktop. Most us e rs ar e familiar with th e concept of a "shortcut". This is simply a 
graphic imag e which can b e placed on th e d e sktop, and which, when clicked upon, starts up th e 
linked to application. If th e shortcut is to a docum e nt, wh e n clicked upon, a compatibl e 
application is start e d and th e fil e op e n e d in it. AppLink s can have e quival e nts to both 
application and fil e shortcuts. 
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This shortcut may contain n e twork location information p e rtaining to an online serv e r 
based application deliv e r e d according to th e thin - client e mbodim e nt d e scribed herein, or to a fil e 
which may be op e ned with such on thin - client based application. One way to impl e m e nt such an 
AppLink "Shortcut" would be a small program install e d on th e us e r' s local PC that displays a 
suitable imag e on th e us e r's d e sktop. On installation, th e program would prompt th e us e r to 
select or e nt e r on e or mor e d e fault onlin e service s , and to e nt e r th e any user name and passwords 
required by e ach s e rvic e for acc ess . Wh e n the "shortcut" imag e is e xecut e d, the program or 
script may automatically activat e th e local thin cli e nt, in th e cas e of a nativ e ly installed cli e nt. 
Alternatively, if th e client is not nativ e to th e machine, th e particular activation requir e m e nts of 
th e thin cli e nt would b e p e rformed. For e xampl e , if th e thin cli e nt i s a Java Appl e t, and r e quir e s a 
web brows e r's Java Virtual Machin e to operate, the script that is the target of the desktop 
shortcut first op e ns a w e b pag e within the browser. The program then automatically logs the 
user in to an applicabl e r e mot e onlin e s e rvic e , and commands the thin cli e nt to op e n the link e d to 
serv e r - bas e d application. If th e "shortcut" ultimat e ly points to a particular fil e , th e file is op e n e d 
in an appropriat e s e rver - based application. The fil e could be located anywhere that the AppLink 
S e rv e r has acc e ss. For exampl e , if th e fil e wa s locat e d on th e us e r's local machin e , and th e local 
machin e 's storage was conn e ct e d to th e s e rv e r, through a protocol s uch as "W e b DAV," or 
Microsoft's W e b Fold e rs, the server - bas e d application could op e n th e fil e , and the user could 
sav e chang es back to th e local machine' s hard driv e . A single AppLink " s hortcut e nabling" 
program would then in e ff e ct e nabl e th e creation and functioning of multipl e " s hortcuts" on a 
us e r's d e sktop. The program would hav e a means to s e l e ct a fil e or onlin e application for 
shortcut cr e ation. A suitable proc es s for this is depict e d in Figure 35. Figure 35 i s a proc e ss 
flow diagram d e picting the cr e ation of an application link int e rfac e according to on e e mbodim e nt 
of th e pr e sent invention. 

Th e e ssential e l e ments that mak e this "shortcut" diff e r e nt from a s tandard AppLink i s 
that th e shortcut will open applications and files without an introductory web pag e , and th e 
applications opened will have full access to all of the us e r's files through a "file » open" GUI 
command. Normally, such file acc e ss permission i s accomplished by requiring a us e r to "log - in" 
to an onlin e application service. In th e AppLink "shortcut" e mbodim e nt, th e shortcut program or 
script r e sid e nt on the user's local machin e would log the user in automatically or otherwise 
auth e nticat e him to the server. A single "shortcut enabling" program, when install e d, can 
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facilitat e any numb e r of s ubsidiary fil e or application AppLink "shortcuts" on a user's GUI 
d e sktop. 

Th e r e sulting accumulation of advantag e s may b e summarized by th e effect of thi s 
structural mod e l. Th e technical int e rfac e provid e d by th e subject invention provid e s for a 
network offs e t which pr e f e rably will l e ad to an incr e as e in us e r or subscriber bas e . In essence, 
on e embodiment of the present invention provid es a n e twork e ffect which builds an e ver - 
increa s ing us e r base due to the app e al of the free or attractiv e softwar e to th e computing d e vic e 
us e r and th e relatively low cost and highly customiz e d data product provid e d to us e rs of th e us e r 
pr e f e r e nc e databas es . As mor e free applications of softwar e arc availabl e , as well as free us e s of 
variou s sorts via th e s e m e ans id e ntified h e r e in ar e availabl e , th e b e nefits to us e rs increase. This 
produc e s mor e user s and gr e ater and mor e valuable busin e ss and p e rsonal database entries 
r e sulting in mor e on e to one, high quality s e rvic e within economi e s. The network e ff e ct 
provided by the subj e ct inv e ntion will pr e f e rably r e sult in extraordinary savings of otherwise lost 
tim e , r e sourc es , and oth e r opportunities not pr e viously addr e ssed or captured. 

Various user interfaces may be used in implementing embodiments of the present 
invention; however, several suitable user interfaces are described herein. Figure 34 44 depicts a 
suitable user interface 4410 serving as a confirmation screen so that the sender of an AppLink 
may ensure the parameters of the AppLink are as intended. The sender may then execute a GUI 
button 4412 to mail the AppLink, edit the parameters 4414, or cancel the AppLink 4416. 

A suitable GUI interface for the receiver of an AppLink is depicted in Figure 35 4$ at 
45 10. The user may enter a password in the text box, download the document if permitted via a 
link, and observe information about the file that is the subject of the AppLink. Various 
informational links may also be provided for general information. However, if a recipient tries 
to access an AppLink that has expired or otherwise terminated, they may be presented with 
informational GUI depicted in Figure 36 46, which may also serve as an informational source 
about the invention by way of links. If the AppLink is successfully accessed by the recipient, the 
sender of the AppLink may be notified by SMTP message as depicted in Figure 37 47, or by 
other communication as detailed above. 

An AppLink sender may be provided with a GUI interface or other suitable interface as 
depicted in Figure 38 48 giving a comprehensive list of all AppLinks which the sender is 
currently administering or are active or pending. The status of the particular AppLinks may be 
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shown. The sender may execute check boxes or otherwise indicate if any files are to be 
manually deleted prior to their automatic expiration. 

Figure 4 9 depicts a suitable embodim e nt of a multipl e AppLink GUI which may serve as 
an improv e d public n e twork portal, or collaborative vehicl e , as d e scribed in d e tail above. 

While a preferred embodiment of the present invention has been described, it should be 
understood that various changes, adaptations and modifications may be made therein without 
departing from the spirit of the invention and the scope of the appended claims. 
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